The following is a guest blog post written by Evan Glazer.
Continuous integrations and deployments are key elements to a company's success in releasing software actively in the multifold. It is common in a small engineering team that only one person has the knowledge to package up the project to release and distribute. Building a system with one engineer understanding how to distribute an application is considered to be a bad practice due to relying on John Doe. John Doe might be on vacation, sick, fired, etc. and due to this new releases are paused from touching production till the next guy figures out all the ins and outs.
Building a system that can actively measure, build and distribute an application is crucial in order to save a lot of time and money. We're going to outline the seven tips addressing the common CI/CD risks that arise when creating a CI/CD pipeline.
Plan Your CI/CD Pipeline Carefully
1. Keep the goal in sight
If you are building processes to implement a few projects with pipelines from scratch, it is important to thoroughly understand how your current projects build locally and what issues you need to account for. It is important to look at your company's 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 such processes in place.
2. Focus on the process before the tools
Before looking at what you can use for CI: Jenkins, AWS, CloudBees 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 and then look at each tool to check if it has the support you need for your project.
3. Understand the needs of each team
When planning, it is pivotal to understand the goals of the team and the skillset of everyone involved in order to be able to understand what you're going to architect. You don't want to create mindless tasks that can make a release or staging release difficult to remember.
4. Pipelines should be matured slowly instead of in one go
When building your CI/CD pipeline it is nice to foresee the future of the CI/CD processes: being able to run unit and integration tests, stress tests, code quality checks, etc. It is essential to focus on being able to build the initial architecture of the basics of the process 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.
5. 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 CI/CD pipeline for: prebuild, build, and postbuild targets. Also, IDEs eventually become outdated and will cause for continuous updates to the specific shell code.
Instead, try:
Create small .sh files or .bat files, commit to your repo.
6. Call for DoD - Definition of Done!
The definition of done is very powerful when understanding the quality standards of what and 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.
7. Lack of meaningful dashboards and metrics
When thinking about the CI/CD pipeline, it is also imperative to be able to understand what each stage in the pipeline is outputting and to be able to identify defects or metrics related to information about testing. A lack of meaningful dashboards and metrics can potentially cause risk with what is actually happening vs what you may envision.
Management and Team Buy-In
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 set, 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.