The very best of Continuous Delivery, Agile and Lean tell us that we should iterate quickly in small steps. To iterate quickly, you want to run locally. Install all your packages and build while you go.
You’re building a bespoke development environment on your machine. Installing packages and dependencies while you create your solution. This works great. It’s quick, it’s easy and at this stage you don’t care about portability because you’re moving fast.
But what’s wrong with this approach? Nothing from a single developer point of view, but what happens when someone else wants to build your code or you want to deploy it? Suddenly a configuration needs to be rebuilt. Another developer’s laptop or another target environment needs a similar configuration as the one you developed it on.
If you’re building software as part of a team, it’s your duty to think about compatibility.
Automated Testing
In addition to configurations being different on different machines, how do we also prove that our software is also functionally correct?
We can write and run tests locally, but we can also choose to continuously integrate our changes with others. Therefore having a centralised CI (Continuous Integration) server that automatically runs tests on push, merge or commit can help us maintain quality and flag up problems before discovering them at deployment time or worse in front of customers.
So much of development work is discovering what works and what went wrong. Automating our testing, automating our deployment, saves us repeating effort in working out where something has broken.
If you’re building software as part of a team, it’s your duty to test.
Continuous Deployment
Assuming a ‘traditional’ DTAP (Development, Test, Acceptance, Production) approach to application deployment – a development environment is also not usually the same size or scale as a production environment. There will be different requirements for production – there will be restrictions, there will be different ways of connecting to resources – there will be different sizes of environments.
Also because often when doing a deployment to a new environment for the first time, there might be things you have forgotten to include in your specification or scripting for environment deployment.
If we choose to leave the creation of our infrastructure and our deployment target too late in the development process, we make more work for ourselves later on. How do we avoid mistakes? We automate. We build our target infrastructure as code and also store that in version control.
If we have our deployment configuration in source control along with our application code then we can run more sophisticated tests (if we like) and eventually also run automated deployment.
If you’re putting your software in front of paying customers, you’ll want to test the deployment easily.
Timing Is Everything
Anything you can do to give you early feedback on your development process, code quality and potential deployment problems is going to save you time when it matters. This means when you have a customer problem, automated testing, deployment and regression will make the difference in making your company stand out.
There is a sweet spot when we can start to introduce configuration into our deployment picture. Many developers see automated tests, and environmental and deployment concerns as details to worry about later. I would argue that they need to be considered even before you start writing your first line of code. Yes adding too much boilerplate work can add complexity to the build and deployment process – but the time you might lose at the beginning will be repaid at the end.