In the first principle, we discussed the importance of having tests in order to validate your code and prevent bugs. In this principle, we explore how to apply those tests on a regular basis through continuous integration. Principle seven is modern applications must use continuous integration.
It might seem obvious and self-explanatory that modern applications use continuous integration. After all, building your project after each commit is the simplest way to run the tests and verify the application. But there are thousands of development shops that lack tests, continuous integration, or both. Why? Most of the time because it’s “too hard to set up” or “too expensive to run.” Neither is a good excuse, and both can be debunked.
Continuous integration can be relatively simple to set up. With GitHub releasing GitHub Actions, continuous integration and running your tests on every commit has never been easier. If you’re not using GitHub but using something like GitLab, you can use their built-in tools as well. And if you’re old school, Jenkins is a better-than-nothing solution you can set up and host on premises for your own purposes.
In terms of cost, there is often a cost associated with running continuous integration. However, this cost is minimal compared to the cost of releasing bugs into production or a broken component making it past QA because nobody ran the tests. It’s best to consider it part of the cost of doing business and accept the cost.
I want to make an important distinction here: continuous integration is not the same thing as continuous deployment. A successful application build does not need to be deployed to production to follow this principle; in fact, you can still have any release cycle you like. Some companies choose to release every build. Others choose to release one a week or every other day. Our sixth principle (yesterday) stated that applications should be deployed often, but deployment cadence is entirely up to you. What’s important is that you consistently build your application so that the tests are run and bugs are discovered early, and often.
Thursday, December 31st, 2020 @ 9:00 am | Comments (0) | Categories: Deployment, Testing
It might seem insane for a team to deploy on a Friday afternoon, at least if they want to enjoy their weekend. But for teams that deploy modern applications, Friday is just another day of the week. This brings us to our sixth principle: modern applications must deploy often and easily.
Ask ten dev shops what their deployment process is, and you’ll get ten different answers. In eight of them, the deployment process will be somewhat to very manual. This means that in those shops, deploying code requires human intervention, often direct human intervention. This presents a problem: the deployment process is only as solid as the person doing the deployment.
To make matters worse, if you asked those shops, 75% of them would tell you that one or two people do the deployment every single time, meaning there’s a high “bus factor” in the event that one of those people is sick or wins the lottery and decides never to return to their job. When only one or two people know how to do a deployment, the business runs the risk of having to reinvent the wheel if those people leave.
What about the other two shops I mentioned, the ones who didn’t say their process involved manual steps? They’ve taken steps to automate the deployment process and make it automatic, so that any developer can kick it off, no questions asked. Maybe it’s a Big Red Button. Maybe it’s a simple bash script. Maybe it’s driven by the continuous integration server (more on that tomorrow). Whatever the process, those shops have taken time to automate the process.
What happens when you automate the process? Two things: first, you reduce the “bus factor” by allowing anyone to do the deployment. Second, you dramatically simplify the deployment process, because complexity and automation are antithetical to each other. What results is a simplified, straightforward process that can be run by anyone from management to junior developer.
Modern applications embrace this kind of setup because the developers know it produces higher quality applications that can be deployed faster and with greater ease. But to get to this point requires application of all the techniques mentioned up to this point: dependency and language version management, testing, static analysis to find bugs, and more. Once these tools are in place, developing an automated system for deploying, and having the ability to safely deploy any time becomes possible. This is the holy grail: the ability to deploy any time, anywhere, without fear.
Even on Friday.
Wednesday, December 30th, 2020 @ 9:00 am | Comments (0) | Categories: Deployment