SCM is SDLC

SCM operations differ from traditional software application development in that changes are often deployed directly into the live ‘production’ environment. We may not always think of our work processes as a production environment since many changes are nothing more than ‘on the fly’ scripting changes, but if we truly believe that SCM is SDLC (and this author does), then these types of on the fly changes are being made in the maintenance phase of a hosted software process deployment. In other words, SCM is Software as a Service.

It can be easy to fall into the trap of ignoring the rigor of pre-release software testing in the case where numerous small changes are being made daily, but if you wouldn’t skip regression testing with a release of application software or in-house, hosted software, then why would you do it with SCM operations – whether it’s a script, application, or process? Are your external customers more important you’re your internal customers, or is it just that external customer complaints are more visible?

Just as application software is tested prior to shipping, any software process hosted for internal use should be tested. After all,

SCM is SaaS

Dependency Management tools have been available to Java developers for a number of years. The developers understand there are potential licensing and other legal obligations when they integrate open source libraries into their projects. This need elevates reporting to one of the core functionalities of the modular build technologies; putting it right up there with artifact publishing and dependency resolution.

Non-Java technologies like Ruby and Python have entered into the world of modular development with Gems and Eggs. This is great, but why don’t they have reporting capabilities in them? I’m not sure why reporting functionality is missing; perhaps a lack of understanding regarding legal obligations; perhaps it is on the road map but hasn’t been developed yet. Is it missing because lack an understanding of how as to how many ways dependency management tools can be leveraged to solve software engineering’s legal problems, or is it simply an immaturity issue with the new tools? Regardless of the reason, it is distinctly lacking as far as I know. I’d be forever grateful if someone would please tell me I’m wrong and steer me in the right direction. I need this reporting capability.

My expectations is that every modular build technology will eventually be equipped with reporting capabilities in some way; perhaps as an extension. And not just the new technologies – all legacy technologies like CMake need to work with modular build environments and have reporting baked right in. Why wouldn’t it happen? Just as the Java developers who liked ant and wanted dependency management ease in Maven bolted on Ivy, I’m expecting to see CMake-Ivy or something similar. The question is: how long will I have to wait before it’s out there for everyone to use?

Why should this reporting be an after thought? A problematic void exists when the first two pieces of functionality, resolving and publishing, are developed ahead of the reporting functionality. Developers are hungry to break up their monolithic code bases into modular builds and start using the management tools without waiting for the reporting capabilities to be available. This void introduces legal risk taking. Is it worth it? Overall, perhaps not, but from the developer’s perspective it is a resounding yes. I see this in the early adoption of Ruby Gems and Python Eggs. The functions save time and should be used. They solve the modular development problem, but leave the reporting requirements lacking.

Can we please propagate the notion of including reporting up front to simplify legal risk analysis into the design decisions when we design new build technologies? After all…

SCM is Dependency Reporting