One Size Fits None
Every modern day successful project has one thing in common; A solid CI/CD pipeline. But that doesn’t mean they all use the same CI/CD pipeline, and in fact they probably shouldn’t. Sure you might use some of the same tools and modules, but plug and play almost never works between teams. The pipeline might be close, but something is always broken or isn’t quite right. Maybe not full on square peg in a round hole, but more like a pyramid peg that might fit one way but not the other.
The Idea
This process is more common in established enterprises looking to move over to this DevOps thing. Even if they are doing things well, there will come a time when somebody will get the idea, “Things are going well in my team, I bet other teams would succeed using my same, exact process.” Or somebody in leadership is asking for a “One Size Fits All” model for this pipeline. The problem is they’re working in a silo, and they probably don’t know what the other teams are doing. Best case scenario, every team can reuse your same CI/CD process by changing some variables. Worst case scenario, you end up breaking your own process trying to shoehorn everybody else in it too.
So how do you get around this? Everybody staying in their own silos will limit the overall progress of a team as a whole. Well the first thing you need to do is learn what other teams are doing. Communication is key in DevOps Culture, and this should be an easy step. Opening up lines of communication between teams to safely talk about, and even demo, their CI/CD process. When you start these conversations you should see some similar steps and processes in place. Finding this common ground should be step one. This will be your focus on reuse; Building your Minimum Viable Product(MVP)
The Execution
Alright now you’ve got an idea for an MVP, how should you decided what to build for first? Let’s say your company has 4 or 5 applications that are your cash cows. Let’s start with one of them. Now who is building this tool? Chances are it is one sad…I mean lucky… individual who will be tasked with this job on top of their day to day duties. So they are going to build a tool to help themselves first. Why wouldn’t they? This is supposed to help their day to day, and they’re the one doing the work. If our MVP is to break an egg, just build an egg breaker that gets the job done right? What could go wrong?
Much like how this project started with communication, communication needs to be prevalent throughout this project. You can’t talk about what you need and then walk away. If left unsupervised to one person who builds for themselves, the tool might end up hyper focused to the style and the process of the builder. So how do you prevent this? Well having a team to build this tool would be the easy answer but that isn’t always an option. Next would be to at least have checkpoints and demos of work so others can be aware of where a project is headed.
These demos should be blameless, and I know what you’re thinking. Why would we go into a demo thinking we’re going to blame somebody? Glad I projected that question on you. It is very easy for all of us to say this is how I would have built something, and you’re doing it wrong. But the fact is we set this person up for failure, and that’s OK. These demos are a great time to ask questions and start testing out your corner cases. This will help your tool become more robust. Only testing a happy path will lead to a lot of unhappy engineers.
Get uncomfortable
The last option, whoever is building this tool should build the tool from the perspective of an application they are unfamiliar with. So if your normal day job is helping payment processing, build this tool to work with user creation first. This will force you to communicate with other teams that are going to use your tool. As well as remove any known happy paths you have in your muscle memory. This option might be the hardest to get going, but will have the best results because you are truly building a tool that anybody can use.
The Delivery
Now comes the hardest part once your tool is built, getting people to use it! Nothing is worse than spending a lot of time and effort building a tool only for nobody to use it. There are few things that you need to do to ensure success, and if you’ve been giving demos you’ve accomplished one of them. By showing users how the tool runs you’re going to eliminate some confusion around how to use this new tool. The next step is documentation, usable documentation. I say usable because we’ve all dealt with bad docs, and it is almost worse than no docs. Documentation should start with what you need to get running, but should grow as you answer questions. If while giving demos you weren’t making note of corner cases and repeated questions you did yourself a huge disservice. Make sure you’re writing down everything you can to make the best documentation possible.
Now you’ve got a working project, lots of people are using it, and all is happy right? Did you already forget what I said up above? Oh sweet summer child, at best with all of this you have made a 90% solution, but we know it’s more like 50% or 60%. Which is fine, this gives everybody a better leg to stand on. Even if it is a 50% solution, people should still be working 50% faster…hopefully. This has now become a solution that you can expand on. Inertia is a great thing, and now that you’ve started this project moving others might be willing to help. And then this new one size fits none project might start fitting a couple people at least.
