We were having some of our systems audited recently. I’ve been part of this sort of things a few times over the years, but I was pleasantly surprised by a number of the questions that were being asked during this most recent session. I’ll paraphrase some of their questions and my answers.
- How do you document your build processes? We have silent build scripts (where possible). The same build scripts are used for each build, with the differences just being environment variables. If a silent build is not possible, we do a semi-silent build, and use screen grabs for the manual bits.
- How do you keep control of your builds and configuration? Everything goes into a cloud-based Git repository, and we have a local git server as a backup of the cloud service.
- How do you manage change through your systems? Requests, Incidents, Enhancements, Tasks are raised and placed in a Task Board, which is kind-of like a Kanban board, in Service Now. Progression of changes to production require a Change Request (CR), which may need to be agreed by the Change Advisory Board (CAB), depending on the nature of the change.
- Are changes applied manually, or using automation? This was followed by a long discussion about what we can and can’t automate because of our internal company structure and politics. It also covered the differences between automation of changes to infrastructure and in the development process. 🙂
There was a lot more than this, but this is enough to make my point.
The reactions to the answers can be summarised as follows.
- When we had a repeatable automated process we got a thumbs up.
- When we had a process that was semi-automated, because full automation was impractical (because of additional constraints), we got a thumbs up.
- When we had a manual process, we got a thumbs down, because maintaining consistency and preventing human error is really hard when using manual processes.
In a sentence I guess I could say, if you are using DevOps you pass. If you are not using DevOps you fail. 🙂
Now I am coming to this with a certain level of bias in favour of DevOps, and that bias may be skewing my interpretation of the situation somewhat, but that is how it felt to me.
As I said earlier, I was pleasantly surprised by this angle. It’s nice to see the auditors giving me some extra leverage, and it certainly feels like automation is a good way to keep the auditors happy! 🙂
Check out the rest of the series here.
PS. This is just one part of the whole auditing process.