What to Consider Before Applying CI/CD | A Beginner’s Cheat Sheet

Continuous integration and continuous delivery (CI/CD) is a complex part of any development cycle. It involves continuously integrating code into a shared repository to keep code progression amongst a team of developers running smooth and steady. This helps prevent merging errors, duplicated efforts and promoting collaboration to create a better product. That code is then thoroughly and continuously tested to keep problems from arising. From there, the code is then deployed to production to be continuously delivered to the live environment. 

As the CI/CD pipeline has many steps and continuously runs throughout the development cycle, that complexity can cause many headaches. After a thorough investigation, we’ve compiled a list of the most commonly asked questions about CI/CD. And we didn’t stop there! We also answered those questions so you can get a better idea of how to solve CI/CD problems. 

What is the difference between continuous integration and continuous delivery?

Continuous integration helps ensure that software components work together. Integration should be completed frequently; if possible, on an hourly or daily basis. This increases the frequency of code commits and reduces the difficulty of connecting code from multiple developers (reducing the chances for non-compatible codes and redundant efforts). 

Continuous delivery is the next step in the CI/CD pipeline. As the code is integrated into the shared repository continuously, continuously testing that code is made possible. There are no gaps while waiting for codes to be completed before testing can occur. This ensures as many bugs are found as possible to continuously deliver codes to production. 

For more details on CI/CD, refer to this blog.

Is continuous delivery worth it?

It depends on your organization’s goals and priorities. Continuous deployment takes a lot of effort to keep the flow going. Once it’s set in place, end users and stakeholders will come to expect that level of deployment. Failing at maintaining continuous deployment after attempting it will not work well for your product’s reputation. Therefore, have a strong strategy in place before implementing this procedure. 

Successful implementation and changing the way the development team runs to continuously deploy at a steady pace has many benefits, such as: 

• Frequent feedback from customers
• Increase the speed at which your product matures 
• Shorter release cycles
• Higher quality 
• Improve team productivity

What is a dark launch in terms of Continuous Delivery of software?

Dark launches are a process in which software is gradually released to the market to get user feedback and test the performance and quality. In order to limit the number of users, the code is placed behind feature flags to control who sees what new feature and when.

Similar to beta testing, dark launches are done on an even smaller scale of users to determine usability and assess how accessing the feature affects the system’s performance as a whole. Facebook, for instance, uses dark launches and calls its tool “Gatekeeper.”

This process ensures there is no hold up to release completed features if incomplete features are still in process. Dark launch the incomplete features and keep it disabled until it is ready for all users to access. While incomplete features are on hold, complete features can then be launched and users can quickly begin using the feature (which in turn allows faster feedback for the development team to use when assessing the incomplete features). 

What is the difference between Continuous Delivery and DevOps?

DevOps is a process that eliminates silos between the Development and Operations teams. To have a fully running DevOps procedure in place, Agile and cross-functional teams make it possible for developers to complete operations tasks, setting up the infrastructure as code benefits. Operations can then focus on writing code to automate deployment pipelines. 

The difference with continuous delivery is that DevOps procedures are not dependent on continuous delivery to process. DevOps can function using biweekly sprints to complete their tasks. On the other hand, continuous delivery works best when there is already a DevOps process in place at the organization. If the Development and Operations teams are separate teams that don’t cooperate, continuous delivery cannot happen (or at least not easily).

Readmore: Continuous Delivery vs. Continuous Deployment: Where to draw the line?

How can I successfully implement Continuous Integration into your product’s development cycle?

Continuous integration is really essential to quickly integrate new code into the main code base. Thus, tests are able to be written and automated much faster than integrating code intermittently (such as every two weeks rather than daily). CI/CD then continues the pipeline with continuous delivery, which continuously deploys thoroughly tested code to production. Those code changes are then committed to the live environment and will reach the end users faster. 

Using tools such as Jenkins, Travis, TeamCity, and Katalon Studio can help with continuous integration implementation while ensuring that quality is met at every step. Automation allows quick access to new products and features which in turn provides a continuous feedback loop from stakeholders and end users, allowing features to be iteratively improved and updated. 

What are some common mistakes made in continuous integration?

Continuous integration is a complex process and mistakes can happen where you least expect them. Below are a few to watch out for while implementing this practice: 

• Not fixing broken builds before adding more code
• Complex branching structures that can be difficult to sort through to find the link needed 
• Using “hotfixes” to release branches
• Shutting off failing tests without first determining the failure cause and location
• Not continuously testing code as soon as it is entered into the shared repository
• Manual testing and manual builds can be used but it will seriously limit the number of bugs caught
• Not writing meaningful tests that can be run against every build to know if anything from the new code affected previous builds

What are the best tools used for continuous integration and continuous delivery?

Amid the variety (and possibly overwhelming) software offerings for continuous integration and continuous delivery, the answer lies in which CI/CD purpose and stage you are at a particular moment. Here are some of our recommendations:

• Source code repository: GitHub, Bitbucket, GitLab
• Continuous integration server: Jenkins CI, TeamCity, Travis CI 
• Build tool: Gradle
• Automated testing tool: Katalon Studio (download now), SauceLabs, SoapUI
• Code infrastructure management: Terraform
• Configuration management: Ansible
• Deployment tool: Jenkins, Docker
• Collaboration: Jira

Read more: Best 14 CI/CD Tools You Must Know

What are the best examples of companies using Continuous Delivery?

That’s a tricky question to answer. The obvious answer is the big name companies like Microsoft and Facebook, but most companies are not to that scale. For this question to make sense for your organization, it would be best to do some research into companies that are of similar size to you (or look at your competitors) to see how they successfully implemented Continuous Delivery. Here is a list of companies who have been successful if you would like examples regardless of size: 

1. IMVU, since 2009 (50 deployments/day)
2. Etsy, since 2010
3. Wealthfront, since 2010
4. DISQUS, since 2011
5. Hubspot, since 2013 (300 deployments/day)
6. Box, since 2013 
7. Tesla
8. Adobe
9. Flickr
10. RESAAS

Does automation play a role in Continuous Integration and Continuous Delivery?

The short answer is: Yes, indeed. Continuous integration and continuous delivery will not be… actually ‘continuous’ without one essential ingredient: continuous testing. Without continuous testing, CI/CD is considered fragmented. Therefore, test automation plays a notable role in the entire pipeline. Implementing automated testing will reduce the time and effort invested in manual testing, as well as the possibility of defects. Shifting from manual to automated testing also means better test coverage, fast product releases, more room for other important tasks – thus, achieve quality at speed.

Check out this free self-assessment to learn where your team is at in the continuous testing maturity roadmap and get expert tips to improve CI/CD, percentage of automated tests, test reports, and more.