Programming is a team activity, which means it's a combination of individual programming and cooperative specification and integration. Once programmers are assigned specific components to code, they work on their own tasks and eventually merge them into a broader test framework that culminates in a complete application test. This process takes time, and continuous integration seeks to shorten the cycle by assigning application components to permit early integration, building test platforms that use the best versions of all components and structuring the transition to ALM from these individual test steps. Container deployment can complicate the problems of continuous integration because development teams often don't test in a container environment, limiting the utility of their early integration work.
Logistics of continuous integration and deployment
The basic notion of continuous integration is that the proper test framework for a given software tool involves the components with which it directly interacts. Therefore, software scheduling and assignments of resources should group components into logically interdependent communities based on which ones interact regularly. As the software development proceeds within each community, the test framework is regularly updated with the latest stable version of each component to ensure that early testing includes component logic as well as integration.
Most logical communities of components are created by natural superior/subordinate relationships. Module A may invoke Modules B, C and D, making them a natural community. In these superior/subordinate relationships, try to assign the superior elements for completion first so their linking function is continuously validated.
In most cases, your component communities will be joined by a small number of bridging components that link into multiple communities, and they should be assigned as soon as testing on communities is reaching completion. As component community testing reaches maturity, these bridging components will join communities into larger integrated elements, a process that will continue until the entire application has been assembled.
That means continuous integration is likely to retain the notion of levels of integration -- the unit-test and systems-test concepts of legacy development practices -- but these integration levels are built and rebuilt as often as confidence levels in the functionality of components changes. The number of integration levels and how software components are promoted to appear in a component community for a given level will depend on the complexity of the code or the changes being made over time. The process of staging components into testbeds is fundamental to continuous integration and deployment, but not all implementations will obey the same rules.
Think of component staging as a promotion process. When a component has been validated in a minimal level of independent testing, it's promoted to a test platform that consists of its component community. When the component has completed testing at that level, it's again promoted to a test platform hosting a bridged set of communities. This process continues until the component has been tested in all the platforms up to the full application level.
A component is added to a test platform so it can be used in testing other components based on a similar set of promotion policies. Most continuous integration users will release a component to be part of an integrated test platform when it has completed testing there, but some users will require that the component also be tested in the next platform up the line. The goal is to ensure that a component isn't certified for testing until it's unlikely further testing will require that it be revised, which might in turn mean other components would have to be retested.
Facilitating container deployment
The notion of component communities is very helpful in planning container deployments because a community would normally map to a container cluster (a Swarm in Docker). Deployment of containers depends on effective use of DevOps tools and container clusters to facilitate efficient resource use, easy connection of applications and users and effective scaling under load or redeployment in the event of a failure. This mapping to container deployment is important because it facilitates a key step; integration component communities must be created, maintained and tested within as close an approximation of production deployment as possible.
Production deployment requirements for containers involve testing the operational lifecycle steps, including deployment, parameterization, scaling, failover and decommissioning. Since these steps will require some accommodation in the development process and the automation of the operational responses through the use of DevOps, the lifecycle steps must be introduced in the continuous integration process as early as possible. Otherwise, you risk incomplete testing and integration as well as defeating the fast-business-response goals of continuous integration.
A critical step in continuous integration is to establish that test framework, and just as critical is recognizing that the framework should be the same as that used for traditional application lifecycle management (ALM). Therefore, it's best to assume that continuous integration and deployment of container-based applications uses a set of container clusters, all identical and compatible with those in which the actual applications will be deployed. This testing-cluster model then seamlessly evolves to support ALM.
Container technology, especially when combined with features that allow for the generation of "portable clusters" that include a predefined set of components and applications, facilitates continuous integration. It reduces the penalty for sustaining test and production environments that represent the phases of testing from unit-code testing to system testing and deployment.
While any virtualization or cloud technology will introduce new integration issues, containers may well offer enhancements to the integration testing process that will more than make up for these issues. Containers go a long way toward the dream of having coding, testing and development practices live within an organized set of sandboxes along with tools to support each stage and practices to control progression of code to the ultimate goal of business use. With care, containers can promote rapid deployment goals overall.
Move forward with DevOps containers
Learning about Windows Server 2016 containers
Can you use containers for portable cloud?