DevOps vs. SCM
• Julian Simpson
There might be a team of people in your company. They could be responsible for:
- Storing built versions of your code in a repository
- Ensuring that you can reproduce each one of those builds
- Tracking changes in the projects
- Baselining and merging code branches
Is that the DevOps team? No. It's a Software Configuration Management team, and they've been around as long as there's been developers.
I believe that these teams will all rebrand as DevOps teams (let's ignore the fact that you can't engender collaboration by making a team responsible for it); but I also think there'll be fewer of them. Here's why:
- Tools are getting better. There's some nasty version control systems in the dustbin of history. Now most people can use Git, and there's no need for a tools expert to help people branch.
- Teams are getting smaller. It's never been a better time to code: we can do so much with a dynamic language and a credit card. Do we need teams of people to help us integrate gargantuan codebases any more?
- Operating Systems suck less: Tell us about your issues writing scripts for HP-UX and Solaris. Pepperidge Farm Remembers. We've got quite the homogenous environment now: you need to your apps to build on OSX and Linux, or Windows.
- Virtualisation and Containers let us test the world: where we used to have test environments with people who would be paid to keep them in synch (that was a cushy number), we can now reproduce the entire thing in docker on your cousin Johnny's old MacBook.
We're still doing SCM and CM. Interestingly, we now seem to use the term Configuration Management as a synonym for System Configuration Management (e.g. Puppet, Chef, Ansible) instead of the generic discipline.
We're still doing CM in the small, without thinking of it:
- made a production branch? CM.
- Identified what changes are in a release? CM.
Remember your history.