CI/CD series - Perforce: polishing the production pipeline
This is a guest post for the Computer Weekly Developer Network in our Continuous Integration (CI) & Continuous Delivery (CD) series.
This contribution is written by Ido Benmoshe, VP of product and solution consulting at Perforce Software — the company is known for its software application developer-focused revision (and version) control system.
One of the questions we have asked centres around the fact that we know that CI/CD is responsible for pushing out a set of ‘isolated changes’ to an existing application, but how big can those changes be… and at what point do we know that the isolated code is going to integrate properly with the deployed live production application?
Benmoshe writes…
CI/CD is aligned with Agile iterative development however CI/CD is a build, test and release automation process that complements an Agile development process. Smaller increments in development make CI/CD more efficient and allows faster feedback.
In general, the best practice is to launch a CI pipeline is onto the smallest code increments possible either on each [code] ‘check-in’ or at a high frequency that suits the specific application, such as hourly or daily. However, keeping tight control over the number of changes made to each iteration requires developers to be disciplined — and even minor changes may still have impact on critical application functionality. Reducing the chance of integration issues requires rigorous testing at multiple tiers – and it requires a high percentage coverage of unit, static code and functional testing, as well as load and endurance testing. Effective CD also requires full automation in building the application environment including the lower testing environments, so that they resemble production as much as possible. It is important to implement detailed monitoring and diagnostics capabilities in the application across all environments to ensure early problem detection and fast resolution.
CD players
In a fast paced and highly competitive digital environments, CD is implemented in order to accelerate time to market of new capabilities, defect fixes and security vulnerability remediation while improving the application quality. Companies therefore implement CD because it provides business ROI and drives innovation and competitive advantages. Failures are usually related to incomplete adoption or poor implementation of deployment automation and more often insufficient test coverage and test automation. Effective continuous feedback does require adoption of monitoring and diagnostics tools.
You asked me does CI/CD automatically lead to fewer bugs?
In general yes the rigorous testing pre and post check in ‘shifts left’ or identifies defects earlier, therefore resulting in faster problem resolution and reducing costly defects from making their way to production. Frequency depends on the business needs, scale of the environment and available resources.
DevOps is a wide space but if we refer to DevOps in the context of infrastructure automation then more effective CD environments implement infrastructure automation for provisioning all the environments however CI can be implemented on manually provisioned systems as well.
Defining deployment vs. delivery
CI/CD contrasts with Continuous Deployment (despite the proximity of the term), which is a similar approach in which software is also produced in short cycles but through automated deployments rather than manual ones… so allow me to clarify this point more clearly.
Continuous Delivery provides the organization with the capability to release high-quality software at will.
Continuous Deployment is essentially an extension of the process in which the changes are also pushed to production automatically without manual approval or intervention. This final production promotion step does not make the process less efficient but rather more related to the business needs.
Image: Perforce