Anyway, back to the CD pipeline. After searching around, I found a few different posts that help outline what a pipeline is. They're mostly in agreement, which is good, but one in particular - even if it may be a bit older - does a very thorough job of outlining the steps. Here's the original post. Here's the relevant pipeline checklist:
All of which should be automated.Unit-tests Acceptance tests Code coverage and static analysis Deployment to integration environment Integration tests Scenario/regression tests Deployments to UAT and Performance test environment More scenario/regression tests Performance tests Alerts, reports and Release Notes sent out Deployment to release repository
In addition to that article, I found a few other interesting links that break down things into bite-sized chunks for me. The first is the Atlassian series entitled A skeptic's guide to continuous delivery, which builds a pretty good use case for anyone who doesn't believe in infrastructure (non-user facing features) investment. It also builds a pretty good for those who do as well, or need a gentle reminder during project planning.
Atlassian also has an entire section on Continuous Delivery. In the interest of full disclosure, I've only browsed through the section, but it does look pretty comprehensive. This article also provides a good general outline of a CD pipeline. Thoughtworks, creators of The Bible on CD, also have a section on Continuous Delivery, but that seems to be a bit harder to navigate and more narrowly focused than Atlassian's section.
Finally, you may ask - why don't you read the aforementioned Continuous Delivery book? The answer's pretty simple. At this stage, I'm not willing to slap down $35 for a 512 page book that I may not finish. A lot of people I know found it extremely useful, but I'm also aware that my tastes in documentation differ from others, so it may not be as useful for me. However, its contents are listed on Amazon, so I hope to peck through each of the sections and do my independent research where needed.
Hey Todd,
ReplyDeleteAs you already know, I'm following your blog :) and I've find it really interesting, because you have a different perspective on some things, which I think is based on your personal experiences, and it makes me think and go through things twice.
I've been through The idea of a fully automated pipeline, and it sounds great in theory, but in practice, I think it becomes really hard to accomplish.
There are a lot of moving pieces that should be mantained to make this to work, that if you lack the resources, 95% of the teams time is spent mantaining the automated process rather than delivering features to the costumers. Ideally this maintenance work should be done by every memeber of the team, but there are people that don't pay too much attention even if it's required for them to do so.. so things start to get complicated after that.
This is my idea of a pipeline based on the one that you've posted, it is slightly different.
* Development - Dev team
* Unit-tests - Dev team
* Acceptance tests - QA team
* Code coverage and sonar analysis - Automated
* Deployments to UAT - Automated - Beta stage
* Create release version - Automated
* Deployment to Performance test environment - Automated
* Performance tests - Automated
* Deployment to integration environment - Automated - Release version stage
* Integration tests - QA team
* Scenario/regression tests - Automated
* More scenario/regression tests - QA team (Analize and create/automate new tests)
* Alerts, reports and Release Notes sent out - Automated
* Deployment to release repository - Automated
* Deploy to production - Automated (Supervised)
Even though those steps are automated, they may still require human intervention and I think all those steps should be in a blocking series, like if one fails, the pipeline should not skip any of those, and no release should happen if the build is not healthy.
Having in mind that the environments and such are not maintained by specific teams or people, I think each step, should have a "Revision" state, where people can spend some time to improve the current step. For example, add new tests, revisit the dev environment health, try different performance tests, upgrade the docker version, etc Otherwise, when times go by, people will start seeing failures that they may want to skip fixing, just to release new changes faster, which goes against the purpose of an automated pipeline. So spending that time, will save the automated process and will pay off in the future, preventing problems and possible defects.
Saludos,
Leo
Leo,
ReplyDeleteI certainly have felt your pain before and can understand that maintaining several components, especially internally, comes with a lot of maintenance overhead. That's why I'm (probably naively) hoping to leverage a lot from running a pipeline in the cloud. Though I haven't gotten to the post regarding this yet, I'm taking a look at https://aws.amazon.com/codepipeline/. If the vast majority of the infrastructure is in the cloud, then the environment maintenance concern begins to diminish. Teams still have to face the possibility that they ignore unit tests, but the phrase 'it works on my machine,' should be much less frequent, since the environments themselves can easily be standardized.
I completely agree with two key components of your original comment - 1) maintenance should be the entire team's responsibility and 2) if any stage of the pipeline fails, then the team should block the build.
Thanks for the response. I also wanted to inform you that you're the first official comment poster on my blog.
Gracias,
Todd