My introduction to DevOps best practices was different. Career experience led me to much of my DevOps knowledge. My journey did not start because management was looking for a silver bullet solution. DevOps wasn't even a word to put on a resume. I learned best practices out of a need to deliver a high quality product and support my teams.
Early in my career, I helped write manufacturing processes for ISO9001 compliance. The overriding rule in the documentation was it should reflect the actual process. If the process had to change, document it. The resulting documentation was available to all members of the company. We encouraged everyone to contribute to the document. This year's State of DevOps has an entire section on documentation. This experience and reading The Goal taught me consistency in process is essential for business. Consistency is repeatability. Once you can repeat a result, you can change variables to get a desired outcome. By closing the feedback loop, your iterations gain purpose. That purpose can range from increasing quality to cutting costs. This ties in with the DevOps principle of "Providing Automation and Insight".
I took this experience into my software career. One of the first things I do in any project is automate the build. Right after that, I try to have a single release point. I never subscribed to the idea of cutting a release from someone's desktop. This was too prone to error and tribal knowledge. The first time I was a lead on a project, I lobbied for a dedicated source control server. Not satisfied and knowing I was not getting another server, I installed build tools on it. Continuing, I added provisions to stand up the application to run manual validations. This was about 20 years ago, before there was such a thing as pipelines.
Shortly after that, I had the opportunity to work on a series of mission critical batch processes. The Operations team asked for monitoring and alerting around those processes. All data center applications logged states into a database log table. The dashboard was a display from this log table. I wrote quite a few processes that alerted from the log table, and I learned the importance of monitoring. Monitoring provides insight to a system. This coupled with metrics keep the systems healthy. The collaboration with Operations forms a primary pillar for DevOps. Expecting another group to deploy and manage your application is unrealistic. There has to be some level of teamwork. During that time, I learned much from the Operations team. Two of those things are preparing an application for deployment and proper monitoring. I am confident the Operations team learned more about what to ask from developers. This makes for smoother deployments and upgrades. An unexpected benefit is a reduction in unplanned work due to failed deployments or upgrades.
Over the years, collaboration with other teams has continued. Collaboration and communication is one of the hallmarks of DevOps. To quote Accelerate State of DevOps 2021, 'The successful execution of DevOps requires your organization to have teams that work collaboratively and cross-functionally.' Working with database administrators improved the application and increased my database skills. Teaming up with Quality Engineering improves test coverage and quality. The reduced testing burden on QE results in quicker turnaround time during testing. Today's threats require working with Security. Earlier involvement from security makes creating a secure application easier. This is the essence of DevSecOps.
One's journey into DevOps does not have to be at a conference, blog post, or in a book. It can come from asking, "How can I help my team?" DevOps can come from improving the product quality or security. Better DevOps can even come from wanting to improve yourself. There is still a lot to learn and I invite you to
continue or start your journey.
Top comments (0)