Does this sounds familiar, there are so many tools, and so much time lost trying to understand them. It seems like we are always chasing a new tool that might fix something in our process. Yet, this tool does a lot more than we need and we could get it done with a tool we already have. Moreover, by the time you get said new tool in house and running, it has been months and now you question do we really need to tool as process has changed.
This has happened to me a number of times and I keep saying I will not do that again. Yet I get plugged into a new project team that needs something and there is a tool for that. Next, comes that enterprise architecture red tape to work with the cool new tool. After which, we need to get all the infrastructure in place, yada, yada, yada. Months pass by.
With hindsight in the mirror I now have a new approach to Tool POCs and it starts with quick feedback. Their are tiers to this as well. If the tool is a no brainer cornerstone type of tool like Gitlab/Github pinned to replace an aging SVN, then well it has to work you just need figure which is best tool. These are Projects and have a different set of rules. My focus for this write up is more on the tool-sets for CICD pipeline, and these types of tools fall into two tiers the pillars like Dataical, DBMaestro, XLRelease, XLDeploy, Tasktop, etc. and helpers Artifactory, Sonarqube, SSDT, Liqubase, Security (Fortify, DTR, X-Ray) etc.
The Pillars are tools that are needed and will help form the base of our CICD base, they tools where you need to be able to continuously improve with. These tools can be expensive and hard to set up thus making them hard to quickly POC (Proof Of Concept). This is where docker comes into play, any pillar tool worth their salt best have an image or two one docker hub. This will allow you quickly spin up a sandbox and get some initial testing locally. If tool does not have an image available is not hard create your own dockfile/compse, yet you need to think is it worth it?
Remember, POC should be about getting as quick as feedback as possible, akin to “The Lean Startup”, this is no different. We need to validate the reason we “need” this tool. I once had a POC of a tool that filled a huge gap and was needed but it took almost 18 months of crap work (AKA political red tape) to finally get the tool purchased. And by that time, the question was do we really need the tool, we’ve been without for this long. In this case, we all knew we needed it, it was right tool, yet we had a very hard time getting integrated with our security settings. With preconceived biased that is was ‘the right tool’, the team kept push to figure out how to get the tool the work. Long story short, take 18 months to get a workflow tool in place, no matter how good it is, it will have little chance of be a success compared to RIO, due to all the RnD that went into it.
This example, shows the power of will, yes it nice to see something through. And yes the tool may be the best practice, but some times the tool just is not right for your situation. As much as you know it is, as much as we want it to work, it just might not and that very hard to accept sometime. Believe me, for my whole career, management has thirsted to make IT as cookie cut as possible, but we all know IT is not cookie cutter type work.
Okay back to the Pillars, for me we need a maximum of 10 working days to POC a pillar, and we should push to have it done in 5 days. Plus a key part of POC needs to be ease of deploying and maintains, does it have a gitops type of update path. No pillar should be hard to update, in fact, we want the pillar to be evergreen it possible. Have a tool be hard to update make it rip to quickly become tech debt!
Okay i have officially gone off the rails with with post, it has no stopping point, no real point, it is really just a jumble of thoughts, I might be here all night if I do not wrap this up. Did I really just introduce tech debt in this post.
Helper tools should be POC in less than 3 days and ideally less than a day. We should be able to them in CICD pipeline the next day after approval. Helper tools should be gitops, and dockerized type of tools. Helper tools should be all about be able to quickly use them and quickly get off down the road. While Pillar tools will no doubt hold logic for your CICD, helper tools should not.