DevOps For Dummies
Book image
Explore Book Buy On Amazon
The growth of DevOps culture has changed the way developers build and ship software. Before the Agile mindset emerged, development teams were assigned a feature, built it, and then forgot about it. They tossed the code over to the QA team, who then threw it back because of bugs or moved it along to the operations team. Operations was responsible for deploying and maintaining the code in production.

This process was clumsy, to say the least, and it caused quite a bit of conflict. Because teams existed in silos, they had little to no insight into how other teams operated, including their processes and motivations.

CI/CD, which stands for continuous integration and continuous delivery (or deployment), aims to break down the walls that have historically existed between teams and instead institute a smoother development process.

Benefits of continuous integration and continuous delivery

CI/CD offers many benefits. However, the process of building a CI/CD pipeline can be time consuming, plus it requires buy-in from the team and executive leadership.

Some benefits of CI/CD include:

  • Thorough automated testing: Even the most simple implementation of CI/CD requires a robust test suite that can be run against the code every time a developer commits their changes to the main branch.
  • Accelerated feedback loop: Developers receive immediate feedback with CI/CD. Automated tests and event integrations will fail before new code is merged. This means that developers can shorten the development cycle and deploy features faster.
  • Decreased interpersonal conflict: Automating processes and reducing friction between teams encourages a more collaborative work environment in which developers do what they do best: engineer solutions.
  • Reliable deploy process: Anyone who’s rolled back a deploy on a Friday afternoon can tell you how important it is that deploys go smoothly. Continuous integration ensures that code is well tested and performs reliably in a production-like environment before it ever reaches an end user.

Implementing continuous integration and continuous delivery

CI/CD is rooted in agile methodologies. You should think of implementing CI/CD as an iterative process. Every team can benefit from a version of CI/CD, but customizing the overall philosophy will depend heavily on your current tech stack (the languages, frameworks, tools, and technology you use) and culture.

Continuous integration

Teams that practice continuous integration (CI) merge code changes back into the master or development branch as often as possible. CI typically utilizes an integration tool to validate the build and run automated tests against the new code.

The process of CI allows developers on a team to work on the same area of the codebase while keeping changes minimal and avoiding massive merge conflicts.

To implement continuous integration:

  • Write automated tests for every feature. This prevents bugs from being deployed into the production environment.
  • Set up a CI server. The server monitors the main repository for changes and triggers the automated tests when new commits are pushed. Your CI server should be able to run tests quickly.
  • Update developer habits. Developers need to merge changes back into the main codebase frequently. At a minimum, this merge should happen once a day.

Continuous delivery

Continuous delivery is a step up from CI in that developers treat every change to the code as deliverable. However, in contrast to continuous deployment, a release must be triggered by a human, and the change may not be immediately delivered to an end user.

Instead, deployments are automated and developers can merge and deploy their code with a single button. By making small, frequently delivered iterations, the team ensures that they can easily troubleshoot changes.

After the code passes the automated tests and is built, the team can deploy the code to whatever environment they specify, such as QA or staging. Often, a peer manually reviews code before an engineer merges it into a production release branch.

To implement continuous delivery:

  • Have a strong foundation in CI. The automated test suite should grow in correlation with feature development, and you should add tests every time a bug is reported.
  • Automate releases. A human still initiates deployments, but the release should be a one-step process — a simple click of a button.
  • Consider feature flags. Feature flags hide incomplete features from specific users, ensuring that your peers and customers see only the functionality you desire.

Continuous deployment

Continuous deployment takes continuous delivery even one step further than continuous delivery. Every change that passes the entire production release pipeline is deployed. That’s right: The code is put directly into production.

Continuous deployment eliminates human intervention from the deployment process and requires a thoroughly automated test suite.

To implement continuous deployment:

  • Maintain a strong testing culture. You should consider testing to be a core part of the development process.
  • Document new features. Automated releases should not outpace API documentation.
  • Coordinate with other departments. Involve departments like marketing and customer success to ensure a smooth rollout process.

About This Article

This article is from the book:

About the book author:

Emily Freeman is a technologist and storyteller who helps engineering teams improve their velocity. She believes the biggest challenges facing engineers aren't technical, but human. She's worked with both cutting-edge startups and some of the largest technology providers in the world. Emily is currently a Senior Cloud Advocate at Microsoft and a frequent keynote speaker at technology events.

This article can be found in the category: