With the rise of automation, and an increase in the use of “infrastructure as code”, IT professionals responsible for systems management are increasingly exposed to new demands, and new risks. It’s therefore worth going back to software development fundamentals, and consider the lessons that are applicable in this new world; even if you aren’t doing full continuous integration/continuous deployment, there are plenty of basic rules that are still applicable.
• Development/testing environments. If you do nothing else from this list, you need to at least have properly configured development and testing environments. Populating them with data can be problematic – the “simple” option of taking extracts from production can expose a whole slew of privacy and security implications that might not be immediately obvious at first glance. But having environments that can be pounded upon, knowing that it won’t impact on the systems your business depends upon for day to day work, but that they will react in the same way as your production systems will let you build, test, and deploy changes with confidence.
• Version control (also known as revision control or source control). The de-facto standard these days seems to be git, with its use being extremely widespread in the Linux community. Having a proper version control system will not only let you coordinate changes and updates better amongst the team, it also means that reverting updates that cause problems becomes much easier. In the context of “infrastructure as code”, everything that can be put into version control, should be – even application and system configuration files. The storage space required to store this data is cheap; the cost in human time to figure out how to fix problems caused by changes is high. Being able to roll back quickly, and figure out what went wrong at leisure, is invaluable.
• Automate testing. This will be difficult early on, as it’s not always obvious what should be tested, and what will just be pointless noise. But over time, you should develop a suite of tests – possibly looking for regressions, or issues that might not be common, or maybe just edge cases. These should be run in as automated a fashion as possible, with as little human intervention as you can manage. The more good tests you have and run, the less likely it is that something will slip through the cracks and cause problems. The more you automate the running of those tests, the less likely it is that you’ll miss a test that would have been caught an issue before it hit production.
All of this is very simple, basic stuff that you should have in place already. But it never hurts to be reminded, and to check that the development system that should be mimicking production does, in fact, mimic production (rather than having decayed and drifted away over time.)
