We kick off the blog series about CI/CD by diving deeper into the CI/CD process and looking at the personas involved. Personas help understand the interactions in the CI/CD process. You should also be able to relate these personas to people in your own organizations.

Understanding the CI/CD Process and the personas involved

As mentioned earlier the CD process picks up where the CI process ends. But what does this mean in a real world environment?

The main purpose of the CI process is to “integrate” code committed by various developers. Integrate here means running the build process that creates build artifacts and then running automated tests on those artifacts. Once the automated tests are successfully completed, the artifacts are said to be ready for deployment. These artifacts are then stored in a artifact repository from where the CD process picks them up and performs the necessary steps for deployment.

As you can see in the above process, there is a Developer persona - someone who writes code to meet the product requirements. Another persona called DevOps is responsible for the tooling to run builds, store artifacts and for deployment. Broadly the DevOps engineers are responsible for the CI/CD process.

The Developer and DevOps interaction

The interaction between Developer and DevOps is worth exploring further because it directly impacts the productivity and agility of the whole team.

In the real world environment, a software development team will consist of many developers. It is important that all the developers use the same version of libraries, 3rd party tools and systems to write and test their code. This consistency is also applicable for the build and deployment process. You would want developers to build the code the same way a CI build system would build. This consistency is implemented by the tooling provided by the DevOps engineers. The picture below describes the interaction between Developers and DevOps engineers.

CI/CD Personas at a high level

CI/CD Personas at a high level

Typically at the start of the project, the Developer and DevOps engineer would sit down and discuss how the software product will be built. This includes decisions about the version of language, the various 3rd party libraries and tools etc. They will also discuss the “developer experience” - the process for writing code, for running tests and submitting the completed code to the source code control system like Github. This discussion results in a set of requirements for the DevOps engineer. The DevOps engineer would then build the tools and systems based on these requirements. And these tools are then available to all the developers, thereby ensuring the consistency of the development process. Tools like Jenkins are used by DevOps engineers to implement the CI/CD process.

CI/CD - Developer perspective

The involvement of developers in the CI/CD process ends when they submit code to the source code control system. Once code is submitted, automated tests and deployment processes take over. But even to submit the code, it is important to have a clear and consistent process. Here is an example of a simplified process as seen by a Developer:

  • Install Git (Git is the source code control system). This is a one-time activity.
  • Check out the full source code repository. This includes documentation and tools for CI processes.
  • Install the tools mandated by the DevOps engineer - the CI tools. Modern software development uses Docker runtime for this.
  • Create a branch and write your code.
  • Test the changes locally in the development environment by leveraging the Docker container built by DevOps team.
  • Once tested locally, submit the code for review and commit to Git.

The important thing to note here is that all developers will follow the same process. All the developers will also use the same tooling that is provided by the DevOps team.

CI/CD - DevOps perspective

The DevOps engineer(s) have a completely different view of the CI/CD process. They are responsible for creating the various tools and systems so that all developers get consistent developer experience. DevOps engineers also ensure that the same technologies and tools are used in the official CI/CD process. Here are some salient aspects about the CI/CD process as seen by DevOps:

  • DevOps engineers discuss the build and test requirements with developers
  • Together, they agree upon the version of the software and libraries, the build tooling and the developer experience.
  • The DevOps engineers then implement the agreed requirements. Even though the requirements were jointly discussed and agreed, the ownership of the development environment, tooling etc lies with the DevOps engineers. This is needed to ensure that all developers get the same consistent experience.

Process for my blogs

I will use my blog writing as an example to explain the concepts dicussed so far. Since I am the owner and author of the blogs, I play the dual role of the Developer as well as the DevOps engineer. Here are some highlights of how I use the above CI/CD model and personas for my blogging.

  • When I write blogs, I basically don the persona of the developer.
  • I use a specific version of hugo and a specific visual theme for my blogs.
  • I use Docker containers to test my blogs locally.
  • The build artifact for my blogs is the static HTML files generated by hugo.
  • I use the nginx Docker image to test the artifacts.
  • Finally I use the aws-cli Docker image to deploy the artifacts to AWS S3 bucket.
  • If I were to add another blog writer (another Developer persona) - all they will need is Git and Docker to be installed. Using these two tools, they will be able to follow the exact same process that I have been following.


We have discussed the two different personas when it comes to the CI/CD process - the developer and the DevOps engineer. Together they are responsible for delivering high quality software products efficiently to the end users.

In the next blog we will look at the specific technologies and tools that I use for my hugo based blogs. We will use that as a reference to show how modern CI/CD tooling can be built to ensure consistency between developers and the CI/CD systems.