This is a continuation of the Four Factors of an Effective Software Development Pipeline, where we will focus on factor four: Legos! Not Assembly Lines. Check out Factor 3: Pipeline Maintenance Should be Free if you missed it.
Factor #4: Legos! Not Assembly Lines
The primary concept of this factor is that builds and pipelines should be both complex and
All that to say there’s no reason we cannot support that and
For example, let’s presume we have three components of our business application:
- Our primary web based
- Finally, we have an internal only application
jakeJSthat we use for team-building and some office-fun.
A pretty standard approach is to build a Jenkins build for each of these and then we’ll worry about the rest later, right? No. Please no!
Instead envision we leverage the previous three factors and we’ve built three separate pipelines in Amazon CodePipeline. At least we’re better off than Jenkins.
This would look something like this:
You’re thinking; fine what’s the big deal? I can get that setup by myself in less than a day and be done with it, and it will hardly ever change so what’s the harm. And when it does change it’s just a silly internal thing so it’s no big deal if it breaks for a little bit. Or any other rationalization you can conjure to move on to the next thing. In the last ~15 years I have heard (and been guilty of myself) them all.
Over time however, this will become a nightmare; trust me. You will end up with dozens or even hundreds of builds, and they will be split across multiple Jenkins build servers which will have different plugins, and your builds will break and you will have no idea how or why, and then you’ll recreate it somewhere else and not delete the old one, and then there will be two builds for someone else to figure out; starting with which of the two actually builds the damn code!
Let’s save our future selves that headache! Think of your pipelines as constructed lego masterpieces. These masterpieces have many of the same lego pieces that we can reuse across more than one pipeline.
For example, we’re using CodePipeline, so let’s standardize how we setup builds all in the same CodePipeline region and environment. Now everything is all in one place; an obvious but hugely important first step.
The point is we identify many similar reusable components, and so we reuse them, all-the-while maintaining our uniqueness across pipelines. If we later determine the testing step needs to be separated, the change process is very straight forward and as simple as cloning the original and updating the new Lambda.
In the end, the complexity of software and business in general is going to largely dictate the technical solutions your teams implement. I simply hope this post and its three related factors articulate a generalist approach that sheds light into some best practices that will minimize the pain and suffering later for you and your teams.
Previously we discussed the second factor, which is to Pipeline Maintenance Should be Free.