Sys Admin/DevOps and developer.
This blog is mainly to display my different projects, as well as a place for me to share and discuss technology news and interests.
I have the pleasure of consulting a company that has not been a startup for a while now. I was hired to implement Continuous Integration, i.e. migrate from an old Perl build script and shared storage system to Automating (Jenkins) the Build (Gradle) and publishing Artifacts to a Central Binary Repository (Arifactory).
Quite often I’m asked “what am I doing?” And sometimes: “What is DevOps?”. Furthermore my boss has asked me to come up with a presentation to get some buy-in within the company to this migration to Continuous Integration.
Presenting the work done automating a Pipeline process, integrating Jenkins, Gradle & Artifactory is actually the easy part
The challenge is actually the introduction to DevOps, i.e. answering that seemingly simple question: “What is DevOps?”
To some DevOps engineers is just the latest-buzz-word-name for what used to be SysAdmins. To other’s they are SysAdmins specializing in Virtual Machines (be it on Amazon, Google or private clouds). Many Build, Operations & SCM Engineers have assumed the title of DevOps, it being the latest buzz word, that allows them to get a lot of attention from head hunters on Linkedin.
Coming to DevOps from the unlikely place of QA management and so having the advantage of seeing the bigger picture, I’d like to pitch the case of DevOps in a non-startup company by explaining how Continuous Integration will expedite the release process by Automation and so better expose the Development Cycle Status to Management.
To achieve this we need to get everybody on board, Dev, QA, IT, Product & Management. So that everybody continues to do their job, but better understand the needs of the other players in the game.
Having said that, it seems to me that this is what DevOps really is. Getting the company to work together, not in silos, not basking in their specific discipline knowledge, rather sharing it and better explaining their needs in order to get their job done. Be it the Developer that wants to code and get fast quality feedback to her work, or be it the IT engineer that is concerned with the ever increase in disk space utilization on the company servers. All parties need not know how to do each other’s job, but they do need to better understand each others requirements and constraints in order to get the job done. The it’s DevOps’ job to get this knowledge propagated across the company.