Thoughts about DevOps and ALM with Continuous Delivery/h1>
DevOps and ALM -do they both fit into the process of software development
DevOps and ALM appear to be very similar, but still different. I recently read a blog about DevOps and how ALM fits into the process. Their argument was that ALM tools, such as source code versioning, is an important part of the process and that there should be a “release vault” where the prod code is stored. I would agree to some level, but the author was missing an important step. Source code is not deployed, binaries are deployed the last time I checked. So just because you have a version control system does not mean that the code that you check into that system can actually compile and execute or that you are actually doing some level of continuous delivery.
The versioning tool should stay on the developer/test/code management side of the house. A build and a binary repository should be the intermediate steps that connect dev to test or prod. A build at Test should be executed from the code stored in the source repository against the prod technology stack. The results should be stored in a binary repository for staging to production.
Production control has little use for source code. Testing should take the source, create the final binaries against the proper prod libraries, test the binaries, store the binaries in a binary repository and mark them for ready to release allowing production control to execute a standard template for deployment.
The author also talked about the use of developer scripts for build and deploy – NO NO NO!!! If we are to move forward in the DevOps space, we must eliminate one-off script driven processes delivered by every development team. The redundancy is costly and error-prone scripts are often the cause of many late nights. As professionals in the “distributed” space, we should get as good as those before us on the mainframe. They dumped private compile and release JCL scripts years ago for improved and automated processors that standardize, streamline and simplify the “DevOps” process on the mainframe (like 30 years ago). What is taking us so long to figure that out? I think on these things often.