DevOps is the new buzzword in software development, especially for web applications delivered as a service. However, for companies interested in getting started with DevOps and good code infrastructure, choosing a starting point often proves to be challenging. Let this be a guide; DevOps is built around the foundation of continuous integration, delivery, and deployment. So, if your software projects aren't currently operating on a CI/CD pipeline, then you should begin by making the switch.
CI/CD has become its own buzzword of late. Many developers and project managers refer to CI/CD as though it's a monolith. In truth, CI/CD is actually a collection of various DevOps practices that increase security, decrease time to production, and mitigate risk. In basic terms, CI/CD seeks to standardise and automate the steps that new code goes through in order to reach production.
Continuous Integration/Continuous Delivery
CI/CD is the foundational set of DevOps best practices on which all other DevOps scaling, security, compliance, and management practices build. Doing CI/CD correctly involves implementing technical changes in how code gets tested and deployed. More importantly, CI/CD involves retraining your developers, project managers, quality assurance team, and executives to work in a new standardized and streamlined workflow.
While many people refer to CI/CD as a singular process, it's actually three separate phases of DevOps proficiency:
1. Continuous Integration
Most software projects use some type of version control. Version management software like Git, Microsoft Team Foundation Server, Helix VCS, Subversion, or AWS CodeCommit, has become standard practice in software development. These version control tools allow developers to branch a copy of the main file, write new code, and then submit a merge request to add their new code to the development branch.
Continuous Integration automates this process, usually implementing a form of test-driven development (TDD), where the developer writes unit tests prior to writing the code. The new code must pass these unit tests as well as other automated security checks. When the code passes such tests, continuous integration automatically merges that code with the main branch.
The result of continuous integration is a drastic reduction in the time and cost spent on quality assurance, writing and running tests. Additionally, continuous integration resolves the issue of conflicting merges when multiple developers submit a merge request at the end of a project. Automating the process means changes immediately get merged in a sequential order. Even with absent continuous delivery or deployment, continuous integration is a valuable DevOps practice to introduce to your development team.
2. Continuous Delivery
Automating the process of merging new code makes it easier to test and build a stable development branch of your software. However, what happens when it comes time to move that development branch to production?
In the past, it might have meant a manager copying files over to the production folder, manually fixing any pathing issues, and then changing the code or URL to reroute to the new production version. There are obvious issues with this approach, and many ways to make a mistake. Continuous delivery automates this process, making the process of moving code to production as simple as clicking a button.
It's important to note that continuous delivery still requires a human to authorise the deployment. However, the deployment itself – actually moving the files – is now automated. With continuous delivery, releasing is no longer a technical decision, and it doesn't require expertise or manpower. Instead, when to release is a business decision, because the code base has already been tested, and the path to access production is secure. This allows for much more frequent releases, reducing risk. It also means rollbacks become much easier in the event of an unforeseen setback.
3. Continuous Deployment
Continuous deployment is the highest level of CI/CD. As soon as new code passes tests and security checks, it automatically deploys to production. This means that as soon as the developer is done writing a new feature, and that feature passes all tests, it deploys directly to production within hours - or even minutes.
Running a development team on continuous deployment requires a strong testing culture and experienced, security-minded developers for code reviews. It also means you'll need to create frameworks and feature flags for code in progress or on hold.
The benefits are clear. There are no pauses in development to prepare for releases. Instead, your dev team is always releasing. This creates a challenge of documentation. As features and functionality constantly update, the user manuals and help desk need to update along with the code. Despite the challenges of documentation and training a test-oriented dev team, the benefit in reduced risk and the customer delight at constant improvements makes continuous deployment a good goal for large projects.
Building Your Software Infrastructure
If your company is not yet using CI/CD, then you can implement these three steps in order, so that the transition is less abrupt and easier for your team to understand. Additionally, many companies choose to forego continuous deployment and are happy to stop at continuous delivery. In many contexts and industries, controlling release timing makes a lot of sense, and continuous deployment isn't a goal.
Regardless of how you implement it, CI/CD is an important process for any company writing and updating software. It has become best practice in the industry for security, compliance, and reduced risk. CI/CD makes business sense because it creates a clear, reversible audit trail of all changes made to the production environment. Faster, tested deployments mean less exposure to bugs, quick resolution of issues, and new features for users on a regular basis.
