Imagine this scenario: You need to set up your software project on a different computer. How many times will you stumble along the way? How long will it take you to fully set up your project on this local machine? One hour? Five hours? Three days?
Here's another scenario: You're working on your software project, and weird things are happening. Did you mess up your local development environment? Can you remember what you did wrong? Will you have to nuke your development environment and start over?
Here's another scenario: A new member has joined your software project. You need to walk this person through the process of fully setting up the project on his/her local machine and having all of the tests pass. How many times will you or this new team member stumble along the way? How many hours will it take for the project to be fully up and running on his/her local machine? One hour? Five hours? Three days?
In this session, I will demonstrate examples of projects where I have implemented my safeguards against the infamous "But it works on my machine!" problem. With my safeguards in place, you never have to live in fear of the day when something happens to your development environment, you need to set up your project on a different machine, or you're responsible for walking a new member of your team through the process of setting up the project.
What's the secret sauce? The two main ingredients in my secret sauce are a custom Docker image and comprehensive Bash scripts in the project. No, you don't even need to submit a pull request for this.
This person hasn't yet added a bio.
This will add your name to the list of interested participants. It will help us gauge interest for scheduling purposes.