Top 10 Pipeline mistakes
23 May 2020 - Giulio Vian - ~2 Minutes
Today I am going to start a series of posts detailing common issues or mistakes in a DevOps context. I will try to refer to my experience and add some practical suggestion to identify and solve these issues.
Let’s start with my list of top 10 CI/CD pipeline issues.
The list
NOTE: Published posts are in bold, the link for items in italic does not work.
- Sloppy handling of Secrets – leaking or hard-coding passwords, tokens or similar sensitive data;
- Untraceable artifacts – when builds produce (or worse: deploy!) binaries of unknown source and version; this is a major red flag because it is cheap and easy to fix, but it is usually overlooked causing a major technical debt pile-up;
- Too specific – if your artifacts are not scrubbed from environment-specific dependencies, so they cannot be deployed to all environments;
- What, quality? – when your pipeline does not contain any check on quality, what do you expect as a result?;
- Bleeding edge – using the latest and greatest technology is not always a wise choice;
- Galactic Builds – far-reaching builds that slow teams down instead of helping them;
- Flaky builds – builds generating unreproducible behaviours or random artefacts;
- Too much of a good thing – when you go too far to avoid the above mistakes, causing the fix to backfire;
- Implicit assumption – any build that breaks when some undocumented environmental condition change;
- Untamed plugins – similar to the previous one, it is the nightmare of people that manage your build environments, when the build software uses too many, or even conflicting plugins.
The list is not really complete: there is one more to add.
The unforgivable sin: having no pipeline
This is the ultimate sin of any developer: having no automated process of any kind.
At a minimum you can have a simple bash or PowerShell script to compile and publish your project.
With that it is going to be easy to integrate it in any of the most popular Continuous Integration tools: Jenkins, Azure DevOps, GitHub Actions, GitLab, TeamCity, etc.
That script should check for dependencies and label the produced artifacts with a version number. This will be discussed in detail in future posts.
If you do not need to automate the process for other people, at least, automate it for your future self!
See you soon with the next episode.