Testing the DevOps approach week 0: Why DevOps

It's been a few years now that I heard about 'DevOps'. I had a few friends that got that job title, they explained to me about what consists the job, but I never had enough interest to do my own research about it. At work I'm the owner (in a software point of view, meaning I'm responsible for the development of new features and making sure that everything works fine) of a few tools that are used in the department (not for the customer of the company). You can see on my other blog post for more details about it. Anyway what is important for this blog post is that now I have one intern that code the new functionality. I receive request for change and suggestion from my manager and coworkers and do the design for the code and the intern do the coding. Since it's live web tools that have to work during the business hours, the release of new code is challenging. I either have to wait for the weekend or after business hours to do the release. Sometimes when it's a quick fix that we need to do, we release it during the day but have to go through the pain of a dozen email complaining that the services don't works, email that my manager receive as well. I also saw that it's very time consuming for me to do the release, and since it's not my principal task to manage those tools, sometimes it overlaps on more important tasks. Here is the process that I have put in place to manage those tools. We use Trello to manage the backlog of work that we have to do, so it's either I or some coworker that have access to the Trello that enters new task to do. I always try to put the maximum of information about the design how to code and ideas for optimization, or sometimes include ways that I don’t want to see in the code. After that I discuss about it with the intern, make sure that he understand the task and the way to do it. We also review the design to make sure that it's a good way to do it, and try to find improvements. It's a perfect way to get involve the intern so he can gain experience in software design from his internship. After that he begins to code it, he create a new branch on the github repo of the project and commit his work daily. If I see that the deadline for a task is approaching I can go start review the code that he wrote and try to debug/help him with coding. Once it's done he do a final commit, I review the code and merge it with the master branch when it's completed and satisfactory. Then begins the trouble of building and testing. I do those tasks myself to keep a control over the code and the process of releasing the websites and software. My team learned from previous experiences that without control of what is released we can have a lot of bad surprises. But in the other side it's very time consuming task.

That's where the DevOps approach enthusiasm me. From what I heard from friends and social media it greatly facilitate the process of deploying and automatic testing of code. After more research about the subject I decided that the approach can be suitable for the projects that I manage. Since it's not my principal task to manage those projects, I can't spend too much of my work time trying new approach for improvement. So I decided to make it an internship for our next intern. Starting from this summer I will have one intern working on coding functionality and one that will implements all the tools and process of the DevOps approach.

On my next blog post I will give more details about the plan of implementing the approach and all the tools and how I see that this can help the software process and quality raise.