How does application container technology affect CI efforts?

I believe that continuous integration is a process and technology that can benefit any development shop. Unless...

your development is limited to integrations between on-premises line of business applications or client-server applications the ideas around CI can help you. Who would turn down finding bugs sooner and accelerating application releases?

CI is the process of having nearly instantaneous builds to an integration environment after it has been committed. The integration environment is shared among the entire development team, from development to QA. And it is where code is tested both manually -- exploratory -- and automatically. The idea is that you can do more frequent builds to learn the effect of new functionalities on an application and catch bugs sooner and do so in a more compressed cycle. This approach benefits applications as they go to production, reduces the overall cost of bugs and improves team collaboration. I call it the "code café."

Although the processes and release automation used to accomplish CI is identical to that used for deployment and delivery, CI is much safer because it does not reach production. It's also faster because it does not go through full end-to-end testing and, in a hybrid scenario, the integration occurs on premises. There are some organizational challenges that come with it, however, including the aspects of getting everyone on the right cadence and willing to work together in a more heterogeneous way.

CI is not and should not be one static environment. This is the most common way to adopt CI, but it is extremely limiting.

But CI is not and should not be one static environment. This is the most common way to adopt CI, but it is extremely limiting. It is held to one set of infrastructure, usually on premises, and code is redeployed on existing infrastructure. If an organization has a two-week sprint, for example, it will do a release to the CI environment at the end of the first week where all new development is stopped. Then the second week is "code free," and effort is spent on refinement and testing the build. This is a way to make releases faster, and seems to be another example of where Agile is used to describe really fast Waterfall.

Instead, CI should be happening on multiple environments and on a commit and pull basis. This should apply to testing as well. You would not run your entire unit and your functional test suite, but you would run tests that cover critical code at every release or commit.

The reason this ideal approach has been avoided, besides the cultural and process aspects, is that infrastructure is heavy and hard to get moving at the pace of releases per commit and pull. This is where application container technology comes in.

Containers also can benefit production releases by building in consistency, allowing applications to be run anywhere, and increasing the speed and frequency of releases. It does the same for CI -- and potentially with greater benefits.

Instead of having one environment per integration build each developer could, theoretically, have one environment per individual builds. The release automation process would spin up a new instance of the container image per commit and pull and then surface access to it via IP for browsing or secure shell. This would mean the developer would immediately visit the running instance and test the new functionality he just built. He would be testing on the actual application stack versus a possibly very muddy development machine or virtual machine, freeing up space and making tests more accurate. In addition, each integration environment can be shared among the entire team if QA wants to get a head start on developing new functionalities and testing scripts.

Tests can be run on each of these individual integration environments and basic testing usually should. Every night the entire trunk of code can be deployed and an entire suite of functional tests run, even in parallel. QA teams know the pain of a functional tests failing at night, so multiple instances of the environment can be run to mitigate the risk of system issues interfering with testing. In the morning there is the entire application built on the approved stack that everyone can test from and review bugs found the night before. This can be done both on-premises and in the cloud.

I believe that robust CI requires containers. Organizations that are cautious about adopting application container technology -- which they should be -- may want to consider the fact that containers can be adopted in a much safer way through CI. The additional security and reliability risk around containers are not relevant in CI, and if something breaks an organization can start over without any unhappy customers -- just a brief delay. So this provides a great opportunity to learn a new approach to infrastructure and application deployments.