CI/CD Should Be Crucial To Any Dev Team

I know I've been raving a bit on this CI/CD topic of late. But, I have to say; it is magic.

Frankly, I'm a little pissed this isn't a normal part of dev education and a normal part of every "Hello World!" style training for a piece of software. The value is IMMEASURABLE.

I logged in today to take a look at some software I wrote for my brother. Right now, they are running 2 systems and this has created a bit of an issue for the backup process. But, I still want to run the backup process for 2 reasons;

1. Find issues and address them
2. More data is better than less if something goes wrong

And one thing which has gone wrong is that when Customers are created in the old system and then orders are created in the new system for those customers, the sync fails because the old system isn't syncing data, so there are gaps. But, in cases like the this, the new system is actually sending the whole customer object, so it is a gap I can actually plug.

When we first rolled the new system out though, it was their busy season and they weren't creating much data in the new system. So, I was fixing the data sync errors by hand. But... now it seems they are using the new system again. There were 41 records stuck waiting to sync. I didn't know how many had issues, but I was sick of fixing the data by hand. I decided to update the code to handle these automatically and about 5 minutes later it was up and running successfully.

One of the keys here is this; I haven't touched this code in months and there is a legitimate reason for that. However, the ONLY thing I needed to be concerned about when fixing the issue was writing the code. I built and tested the pipeline months ago. I knew it would do what needed to be done. And it did. 

And THAT is why CI/CD is a dev concern and why every dev should be in love with the concept; Once in place you can focus on code. There is little, as a developer, which I hate more than deployments. Especially deployments on software I haven't touched in ages. 

And, even better, the pipeline scripts are part of source control and they serve as a form of documentation of the deployment requirements. So, the working developer in me also sees this as a way to help refresh my memory to assist in answering questions from IT/TechOps, new hires and upper management. Again, all things which get in the way of the coding I love. 

So, while CI/CD may not feel like a task which a developer should be involved in or even enjoy... the fact is that it is actually the developers who are likely to benefit the most from it. And, as the system architects they are often SMEs in setting up the initial environments. So, why not automate that setup as much as possible? I mean, deployments ALWAYS come back to bite you when there are manual steps involved.

Lastly, one of the biggest problems I think a lot of developers face is around technical debt. Not having a deployment and testing plan in place can make it difficult to sell customers and management on larger shifts like upgrades to development stacks and libraries.

But, a CI/CD which includes separate setups for dev, testing (QA/Staging/etc...) and Prod combined with unit tests and integration tests (and perhaps even security audits) can set the stage for making those sorts of changes more easy to accept. But, that is all predicated upon having that "proper" multi-dimensional pipeline in place as early as possible. If it isn't there, then you also need to fight to get that in place which is harder after the fact. But, most experienced developers understand the value of doing something right if they are going to do it at all. And so, the notion that developers forced to do CI/CD also pushing at that time for a proper process around dev, testing and production is not too far fetched.

In fact, any developer with more than a few years under their belts would likely insist on incorporating this sort of flow. There is little worse then spending time on a problem only to have it turn out to be environmental or user error. And even if CI/CD only covers one Production deployment it can prove that there are conditions under which the software behaves as expected when the pipeline and tests run successfully.

And, in a modern world where software is increasingly XaaS ("X/something" as a service"), we are also increasingly moving toward a place where there is only a single production deployment to be concerned with. Meaning, if the pipeline succeeds then you may have eliminated those scenarios entirely. 

That being said... if you have a TechOps team or someone who can take a more 1-dimensional pipeline and expand it to cover other use cases, then by all means let them. But, I still think that the dev team should own the initial CI/CD work and that it should go as far toward a full build, test and deployment cycle as possible. It makes the dev team responsible for the work which should, if done correctly, allow them to stay focused on the code.