6 Common Risks: Working with CI/CD Pipelines

This is a guest post from Evan Glazer .

Continuous integrations and deployments are key elements to a company's success releasing software actively in the multifold. It is common in a small engineering team that only one person has the knowledge for packaging up the project to release and distribute. Building a system with one engineer understanding how to distribute an application is a bad practice. If everything depends on one employee, what happens when that employee is on vacation, sick or gets fired? The new releases are paused from touching production until the next person figures out all the ins and outs. Building a system that can actively measure, build and distribute an application is crucial in engineering to save a lot of time and money with not spending a whole workday or two on releases every two weeks.

Here are the six common risks that you should keep in mind when creating a pipeline and how to communicate with your management to receive their approval for buy-in.

Keep the goal in sight. If you are building the processes from scratch to implement a few projects to have pipelines, it is important to thoroughly understand how your current projects build locally and what issues you need to account for. You should also look at your companies current CI/CD implementation for other projects first, and plan out how you can tie in a new project to the current system if your company already has processes in place.

Focus on the process before the tools. Before looking at what you can use for CI -- Jenkins, AWS, Travis CI, Circle CI, etc and all the plugins to achieve the best CI/CD suite for getting your project to production without any issues -- it is very important to build and test the process you want to implement at then look at each tool if it has the support you need for your project.

Understand the needs of each team. When planning, it is pivotal to understand the goals of the team and the skill set of everyone to be able to understand what you're going to architect. You don't want to create mindless tasks with the process that can make a release or staging release difficult to remember.

Pipelines should be matured slowly instead of in one go. When building your pipeline it is nice to foresee the future of the CI/CD processes with being able to run unit and integration tests, stress tests, code quality checks, etc. Being able to build the initial architecture of the basics of the process is essential to focus on from the start rather than measuring components. A simple process may be to achieve the following: clone your project, build and package and receive responses based on what happened when pushing to production (ex: app store).

This figure shows a CI/CD model for being able to package, have integrations, deliver, and deploy with how the pipeline will function.

If you're Storing long shell commands, you’re doing it wrong.

Having your shell commands stored in the IDE will cause issues long term. Not only will it make things harder to maintain and figure out in the future, but it is stronger software craftmanship navigating to a deploy file and seeing the stages of the pipeline for: prebuild, build, and post-build targets. Also, IDEs eventually become outdated and will cause continuous updates to the specific shell code.

Instead, try:

Create small .sh files or .bat files, commit to your repo.

The definition of done is very powerful when understanding the quality standards of what, how the team produces. It provides visibility into the process, alongside including how to implement CI/CD, as well as fosters trust. This is part of the mindset shift that must take place. If the DoD is unclear, the team must define it together and make it visible and accessible to everyone.

When thinking about the pipeline processes, it is also imperative to be able to understand what each stage in the pipeline is outputting and being able to do to identify defects, and metric related information about testing. A lack of meaningful dashboards and metrics can potentially cause risk with what is actually happening vs what you may envision.

The shift to CI/CD is usually triggered from the bottom up, but at the end of the day, it’s a transformation that requires management buy-in because it’s about skill sets, processes and several areas to which management needs to allocate the proper time, resources and attention. DevOps is a very intricate component to software in terms of building software that can actively measure, build and distribute an application actively.