An introduction to DevOps and CI/CD

Here, we’ll provide an introduction to DevOps, pipelines, and CI/CD for beginners. We’ll cover key CI/CD concepts, terminology, and point you to resources that can help you build your first CI/CD pipeline.

What is DevOps?

We’ve defined DevOps before, but let’s have a quick review before moving on to CI/CD. As you might expect, DevOps is all about collaboration between development (dev) and IT operations (ops). Specifically, DevOps focuses on three key pillars:

• Culture. DevOps culture focuses on communication, collaboration, and shared responsibility between dev and ops. People and how they collaborate are at the core of DevOps.

• Best practices. While practices vary from team to team, there are many popular DevOps best practices such as: implementing version control, adopting automation, and CI/CD (which we’re about to explore in-depth)

• Tools. No specific DevOps tool or tools equate to “doing DevOps”, but there are plenty of tools that help enable the best practices that a DevOps culture promotes. Generally, these are tools that help streamline DevOps pipelines.

As demonstrated by Google’s State of DevOps Report, the reason DevOps culture has become so popular is it has proven to help teams become more efficient, ship products faster, improve quality, and increase customer AND employee satisfaction

What is CI/CD?

CI/CD is short for continuous integration/continuous deployment. CI and CD are related but have different definitions so let’s take a look at each separately.

Continuous integration

Continuous integration is a development practice that involves developers on a team checking-in (integrating) their work frequently (usually multiple times a day). Once the work is checked-in, an automated build and testing process kicks off to see if it conflicts with existing code (these conflicts are called integration errors).

The CI process allows teams to quickly detect and correct integration problems and keep everyone’s development code relatively up to date while they are working. Without CI and frequent check-ins, builds, and tests, code different developers are working on could get so out of sync, that productivity and code quality is negatively impacted. Why? Because with fewer check-ins and tests, a developer may work on code for days before they attempt to merge it with the main branch. If they do and there are conflicts, they now have to work through days – as opposed to hours – of their own and their teammates’ code to resolve integration issues.

To understand how CI works in practice, let’s go through an example. 

1. A developer pulls existing code from a team repository

2. The developer works on the code, and confirms their changes work locally (making sure to do build and unit tests of course)

3. The developer commits the code back to the main repository

4. A CI server automatically builds and tests the new code

5. If the tests pass, the developer is done and moves on to their next task. If the tests fail, for example, because someone else made conflicting changes after step 1, the developer must repeat steps 1-4 to address the integration error.

While it may be a pain for our developer to need to resolve the integration errors now, with everyone on the team doing so regularly, there are benefits. Specific benefits of CI are that teams resolve issues quickly, testing is automatic, and there are fewer major integration issues overall.

Continuous delivery

Continuous delivery a.k.a. CD is the next logical step after CI. After the build tests pass in CI, the code is deployed to a staging environment of some sort. At this point, additional automated tests and integration tests are run. If all tests pass, the code is “production-ready” but the code is not automatically deployed to the production environment. Generally, there is manual testing or approval before deployment to production.

This CD process helps speed up deployment times and catch bugs faster thanks to automated testing.

What about continuous deployment?

In addition to continuous delivery, there is another “CD” related to CI/CD: continuous deployment. This CD goes even further than continuous delivery. With continuous deployment, if all tests pass, the code is automatically deployed to production.

The benefit of continuous deployment is simple: production users get the most up-to-date code that was able to pass all required tests.

Understanding CI/CD pipelines

A simplified version of the CI/CD process end-to-end is:

Code changes made → code built → tests run → code released

Of course, in the real world, there will also be planning, failed tests that loop back to step 1, deployment to production, and other details, but that’s the CI/CD workflow in a nutshell. The tools, infrastructure, and practices that implement CI/CD workflows are known as CI/CD pipelines. 

There are plenty of ways to implement DevOps CI/CD workflows, and no two CI/CD pipelines are exactly the same. However, continuous testing and automation are two of the most fundamental aspects of CI/CD common to all pipelines.

CI/CD pipelines: A practical example with JFrog Artifactory

Thus far, we’ve covered the basics of CI/CD concepts. However, in the real world, things get a bit more complex. For example, there will often be multiple tools involved, e.g. GitHub for version control, a CI server like Jenkins, a security and compliance scanner like JFrog Xray, and an artifact repository like JFrog Artifactory. Here is an example of what a real-world CI/CD pipeline might look like:

Source

Let’s walk through what happens in this pipeline:

1. A developer makes changes to code.

2. The changes are committed to a branch in a version control system (e.g. GitHub).

3. A CI tool (e.g. Jenkins or TeamCity) automatically builds the new code.

4. The code is deployed for automatic testing. Artifacts are also deployed to JFrog Artifactory (e.g. in a development repository) and scanned using JFrog Xray.

5. Automatic tests are run.

6. JFrog Xray analyzes the build for security vulnerabilities, license issues, and dependency problems.

7. If the tests/analysis fail, the code is rejected back to the developer for rework.

8. If the tests/analysis pass, the build is accepted.

9. The build is promoted, and artifacts stored in JFrog Artifactory (e.g. in a production repository).

Next steps: Getting started with your first CI/CD pipeline

Ready to get started creating CI/CD pipelines of your own? Head over to our JFrog Pipelines QuickStart Guide and put what you’ve learned into practice! By following our guide, you’ll have your first “Hello World” project up and running in no time.