Embed from Getty Images
According to Forrester, “modern software delivery practices use an automated pipeline in which code is delivered, built, tested, and deployed with limited manual intervention“. (TechRadar: Continuous Software Deliver, Q3 2016 (Updated)). Indeed, this modern pipeline means that “Continuous Delivery (CD) is Replacing Application Life Cycle Management (ALM)“. So how different is continuous deliver compared to our old manual processes and even the processes that we have put in place with our automation tool: BuildMaster?
Under the old way of developing applications the developers would build some code, test it on their workstations and when a bunch of code had been checked into the code repository, a build would occur. This build may or may not be deployed to a System Test environment for someone to do some manual testing. After it passed the same package would be moved to the User Acceptance Test environment where it would be tested by business clients. If it passed it went to production. If it failed it stated the process all over again. This is why La Sagrada Familia is still not finished. (OK, it’s not but it gave me the chance to link another site to you.)
Modern software development doesn’t necessarily do the same things. Automation takes care of many pieces, in a much shorter period of time. For instance, once the code is checked into the code repository a build is created. Not necessarily at the end of the data, but whenever the code is checked in. And the build? Well, the build does some automated testing. Using known test data a series of tests are performed on the code to ensure that it meets the specifications for the piece of code that was changed. If it passes, why, then it goes into UAT for testing.
At this point, there is a bit of a religious war amongst continuous delivery aficionados. Some believe that additional automated tests are done at this stage and if the code passes it moves into production. All without a single human testing the application. Amazon is a great believer in this as they move changes into some environment every couple of seconds. Every day. They have no time to test, so they automate their tests. They even automate performance tests. if the code passes it goes to the next stage and if it doesn’t it gets fixed. But humans aren’t really involved in the process. Some companies want there to be some human approving the migration into production. Someone who is the “owner” of the application and will take responsibility for it. They want a resting point, a place for reflection, to determine if the application should move into production and when that move should occur.
I’m a little bit on the fence. While I would love the first approach, moving straight into production if it passes all of the testing, I know that as an organization we are not culturally prepared for it, nor are our applications designed properly to facilitate this. The straight-to-production approach works if you are dealing with smaller, discrete code bases that can be tested and moved easily. We have monoliths, giant 2001: A space odyssey monoliths that have the potential to change human evolution every time we deploy a new version. (Hey, my blog, my artistic license.) I’m not sure that we have a choice with monoliths. I think that we need to stop someplace, probably UAT, and evaluate the impact before moving into production.
But that doesn’t mean that we can’t automate testing in the lower environments and, to some extent, in UAT as well. Indeed, we should automate testing as much as possible. We should automate the movement of the application as far up the tree as possible. And BuildMaster is the tool that we can use to help us get there. In conjunction with the actual build process itself in Visual Studio, we can ensure that if an application is successfully built and passes the initial testing it gets moved automatically into the next environment. And if we can automate the testing in that environment, fantastic.
In order to do this, we need to break our monoliths apart into smaller, more discrete components, that can be individually tested. We build a series of interconnected pieces instead of a Stanley Kubrick nightmare and automate the process of continuous integration, continuous testing and continuous deployment.
We can do this. We have to do this.