Building and delivering digital products in a fast-paced business environment requires agile leadership, DevOps best practices, and a CI/CD process. Businesses that manage to implement CI/CD best practices can create advantages and digital operations efficiencies that reduce the development cycle time and help to launch products faster—a prerequisite for creating digital disruption. This article is about the concepts and CI/CD practices for project managers and a baseline to start a discussion on the practices to improve the frequency and reliability of delivering software.
Successful software developers adopt routines to build automated pipelines that integrate code (CI) and turn it into production (CD). They also build automated pipelines and adapt their usage to their routines so that code integration (CI) becomes easier without manual intervention and deployment so production is clean and quick (CD).
A repeatable and reliable release process is the key to reducing the cycle time of the project (i.e., the time it takes to deploy code changes or bug fixes to release).
CI/CD Best Practices to Build—Test—Deploy—Release
CI/CD practices are about the optimization and automation of the process of building, testing, deploying, and releasing software. Developers, testers, and IT operations (agile teams) in a value stream align their efforts and implement mechanisms and processes for creating quality products from ideation to release.
DevOps practices follow agile principles to create reliable, visible, and repeatable development processes, lowering risks and costs during releases, which benefits customers. In addition, agile teams practice collaboration and fast feedback throughout the development cycle to quickly detect and fix problems or changes.
There are many activities and risks associated with building software that must be addressed during the initial stages of a project, and developers must keep up with the progression or evolution of changes. This refers to the optimization of activities that mitigate issues about configuration management, databases, testing, environments, integrations, dependencies, compliance, auditing, etc.
Technical leaders at Krasamo help clients decide which practices apply to their specific projects and how to join all activities to create an efficient and reliable process. Implementing an approach with the right CI/CD practices is critical to developing quality software.
CI/CD Process—Automating Activities
Automating all activities gradually will ensure developers build, deploy, test, and release the app efficiently. Engineers set goals to do internal releases and get accustomed to releasing frequently and fixing defects as early as possible. Developers work in small steps and make changes incrementally.
CI/CD best practices take us to the automation of the following activities in the deployment pipeline:
- Build process
- Deployment and release process
- Acceptance tests
- Data migration
- Network configuration
- Infrastructure automation
- Monitor and reporting
Continuous Integration
Continuous integration is building and then testing after every change in the application. The goal is to have the app in a working state at all times. CI/CD best practices suggest doing regular integrations every time a change is committed to version control (VC).
Developers using continuous integration (CI) create automated tests and run them after new changes to prove that the app is working, thereby avoiding any accumulation of problems. CI is a practice that results in faster delivery, with issues and bugs fixed immediately to keep the software running, thus reducing development, release time, and costs. Following CI/CD best practices requires using a code base in a version control repository, running an automated build process, and utilizing a disciplined development team committed to adopting these essential principles and practices.
Developers must ensure all requirements of software and settings are configured into the version control, practice regular commits, create a test suite (unit tests, component tests, integration tests, acceptance tests, etc.), and run it for each commit (if applicable) to protect the app functionality and keep the build and test process as simple and short as possible. Developers ensure source code, scripts, tests, dependencies, libraries, and components are stored and/or configured correctly in a Version Control System, if possible. In addition, ensure CI/CD best practices by identifying code breaks and errors and fixing them before moving to the next task.
At Krasamo, our development teams support continuous integration practices and continuous integration tools to support and execute workflows, check commits compilation/static code analysis, run scripts (either for automation or any other jobs), compile the code, run the tests, and build reports (outputs) with the build’s results. Developers with the tools, platforms, and capabilities can keep a deployment pipeline in a deployable state and deliver code anytime, which builds confidence between the agile team and the project’s stakeholders.
What is a Deployment Pipeline?
A deployment pipeline is the modeling of an iterative process for delivering software. It’s the organization and implementation of an automated process (from initial code build, deployment, QA, and release). For a successful deployment pipeline, well-defined practices for continuous integration must first be defined and implemented. Hence, there is confidence when those steps from the build pass to then being able to deploy. As a result, it becomes a reliable and repeatable process that helps to avoid errors and bugs.
The deployment pipeline manages and controls changes throughout the various stages (propagate) from concept to launch (value stream) of independently deployable units. Each stage triggers the next one. Creating automated builds and deployment using scripts (deployment script) creates updated and complete documentation, simplifying developers’ lives. CI/CD best practices promote deployment scripts that can be used in every environment, allowing one to test its path in a sequence many times before releasing. It’s a mechanism that challenges the code by testing to see if it fails, creating a value stream model (map) for your team to follow.
The CI/CD process is visible to all team members. It improves from feedback to solve issues early and often, enabling fully automated deployment and release of any version and environment after several iterations on its automation/configuration, which maintains code in a releasable state. Additionally, automated processes are auditable and less dependent on people (deployment experts); therefore, it is less expensive than manual deployments.
CI/CD best practices indicate deploying the same executable code (reuse) in every environment defined in the application lifecycle management strategy and test changes in app configurations and/or environments. We refer to any changes in operating systems (OS), network, infrastructure, software stack, data structures, or external systems, as these can affect the app’s behavior.
Version Control: Developers create a repeatable and reliable CI/CD process and manage all artifacts in the version control system—a continuous delivery practice. A fully automated process can be implemented from VCS to deploy the application. It is recommended to keep all artifacts in the version control and uniquely identify them in sequence. This will allow us to build and deploy to any environment. Key elements that go into version control:
- Source code
- Requirements and technical documents
- Defined configurations (files)
- App version and configuration
- Test scripts and test cases
- Deployment, database configuration, and network configuration scripts
- Libraries and toolchains
- Release plans
- Dependencies, binary images, compilers, etc.
A configuration management strategy is needed to record the evolution of the app development and how the team collaborates during the delivery process. A team managing configuration efficiently can reproduce or recreate any environment and configuration, make incremental changes and deploy to any environment, see and trace changes previously made, and achieve smooth team collaboration. A version control system with rigorous configuration management ensures control of the CI/CD process and the application’s behavior, allowing it to retrieve the latest working version any time. Once changes are committed to version control, it provides visibility and becomes available to all developers on the team. CI/CD best practices indicate committing changes incrementally (in small batches) and frequently to the trunk (main branch)—allowing refactoring, if needed, to improve the product. Automated tests are run on the main branch (trunk) after checking in new changes.
In certain situations, developers create separate branches when building new functionality and then merge them with the main branch when the code is satisfactory when its specific job builds successfully. Before committing new code, developers create tests that run on production-like environments (triggered by CI), which introduces changes incrementally to the main branch. This way, everything is tested and compiled before integrating. Although configuration information access mechanisms are beyond the scope of this paper, our development team is more than happy to discuss the considerations in managing the app configuration, testing configurations, and other CI/CD best practices to implement.
Build—Commit Stage
Developers build code and commit changes to the version control system (VCS). The first step is to connect the version control (VC) with a Build Management System (BMS)—such as Jenkins, for example—and a testing tool. The first stage is the commit stage, triggered by code changes made to the app and then pushed to the version control system. Every change made (either code, configuration, scripts, tests, etc.) that is newly stored in the version control system may trigger a new build CI/CD execution.
In the first commit, you commonly compile the code, run unit tests, analyze code health with tools such as Static Code Analyzer, and create installers. Then, the code is assembled into binaries and stored in the artifact repository. In a few words, changes in the source code result in a new build and test of the built binary. The pipeline runs test release candidates to ensure the binary code, data, environment, and configuration mechanisms are properly running. Creating a pipeline requires creating binaries (outputs—computer readable files) and installation packages (installers) for creating an automated process (a continuous delivery practice).
The commit stage passes and results in a “Release Candidate” (output), which is saved in the artifact repository, and goes to the next stage for further testing (deployment to a production-like test environment). At the same time, the team keeps working on new features in parallel. The commit stage detects failures of changes introduced by developers and provides feedback. It launches the automated process, builds binaries, runs automated tests, and creates metrics. The process gives you exact information about the instance that breaks the app.
Developers at Krasamo practice Test Driven Development (TDD) throughout the pipeline—writing tests before code (to create testable code).
Test—Acceptance Test Stage
Automated acceptance tests are run from code created in the commit stage (release candidates) to validate functional and nonfunctional requirements and business acceptance criteria (associated with stories). Automating acceptance tests evaluate the code from a user perspective (user center testing) and are critical for implementing a deployment pipeline. These are run after the commit tests have been approved.
Developers create a test suite and run it as part of the pipeline to verify the business value and to protect the app functionality. Acceptance testing tests stories against the running application and provides a high level of confidence and releasability. Acceptance tests aim to eliminate manual regression testing, protect against large-scale changes, and enable continuous deployment.
Other tests are performed to the release candidate at this stage, such as smoke tests, performance, usability, security, throughput, latency, etc. Krasamo engineers can talk to you about testing scenarios.
Acceptance testing tips:
- Add acceptance testing from the beginning
- Create a test for every story (criteria)
- Create executable specs for the desired behavior of the code
Manual Testing
Manual testing is useful in certain situations for validating usability and requirements and detecting errors or defects. Also, they are used if some integration tests cannot be fully automated. Exploratory, usability, and capacity testing are some manual tests that follow acceptance tests.
Manual testing validates acceptance tests and system behavior. Manual testing can detect errors and bugs with greater precision than automated tests, but they are slow and expensive. In addition, testers update the status of release candidates after passing manual tests.
Release candidates that pass testing proceed to the deployment stage. After deployment, you run acceptance tests again.
Automated testing
When preparing to release software, which can be identified by various indicators such as being in a release branch, it’s crucial to run automated tests. These tests may include business-written tests that are automated, tests that generate data for business use, and unit tests and end-to-end tests.
Deployment to Production
Once the build passes all its tests, security checks, and static code analysis, it is released into production. Operations teams, QAs, and developers must approve deployments before they go into production. However, continuous deployment is when changes are deployed automatically into production, which can start as early as when a new line of code or configuration step stored in version control is pushed since this would start a new build with all the checks and required automated testing. Therefore, if successful, then it will automatically be deployed to the production environment. Continuous deployment can be risky if not implemented appropriately.
Summary of CI/CD Best Practices
- Keep all elements in place to reproduce software consistently.
- Make all changes through the version control system.
- Keep a current version and keep branches short (merging constantly).
- Provide quick quality feedback.
- After a successful commit, developer moves to the next task.
- Automate provisioning of infrastructure—a key aspect to reproduce our system.
- Store release candidates in the repository.
- Create flexibility by using the same deployment mechanisms (throughout the pipeline).
- Consider data changes and migrations as part of the deployment process.
Integrate security testing into the deployment pipeline.
In conclusion, many scrum teams are adopting CI/CD into their processes to help them meet deadlines, ease their workload, and add a layer of security and high standards to the code that is developed and tested. At Krasamo, we integrate these DevOps best practices starting from the intake until an application is delivered, which ensures high quality.
