######[Author: Evan Glazer]
Continuous Integrations and Deployments are key elements to a companies success in being able to release software actively in the multifold. It is common in a small engineering team that one person has the only knowledge for packaging up the project to release and distribute. Building a system with one engineer understanding how to distruibute an application is said 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 engineering to save a lot of time and money with not spending a whole work day or two on releases every 2 weeks. We're going to outline the 6 common risks that you should keep in mind when creating a pipeline and how to communicate with your management to receive there approval for buy in.
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. It is important to 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.
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.
When planning it is pivotal to understand the goals of the team, and the skillset 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 rememeber.
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 componenets. 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.
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 out dated and will cause for continous updates to the specific shell code.
Instead, try:
Create small .sh files or .bat files, commit to your repo.
The definition of done is a 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 or 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 invision.
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.