Hi Folks…
We are hearing “DevOps” buzz word these day often….so I thought of writing my understanding on it from release perspective.
What is it? What impact it can put on us?
Let’s think of life without it….let’s sit on time machine and go in the past…How IT worked during that time? Company has business and they need IT to automate its activities…Business gives the requirements to IT. IT has many groups, like Development group, QC/QA group, operations group that deal with production/infrastructure support etc.
Information flows from one group to another in a sequential manner. Once IT receives requirements from the business, it does some feasibility analysis and then assigns the same to the development group. This assignment can be manual (via emails/excel) or through some tools.
Development team starts working on it and their only goal was to implement the requirements given by the business and they have not had any idea about the actual production environment. Development team are using tools for versioning their code and they may or may not be using any tool to automate the testing/build.
In absence of any tool, they had to do building of code and testing all manual. With long deadlines and once in a while release, it worked fine. Development team writes code and at the end of coding they were doing full builds and the system testing. Finding what broke their existing feature is a costly thing. But all well, as far as, they are delivering the software to business. Business will find the issues, they will contact Development team again and the same process will go on till the time acceptable software is delivered to operations.
Till this time there is hardly any talk between Development team and operations. Many times operations with their understanding of production, have many important recommendation/s, but since they are in picture at the end, Development team doesn’t accept their recommendations and they have to carry on the release. Operations might find it difficult or even not possible to put the software in production as is, as it is not designed in a way, software can be hosted on that particular environment. Good example, is with XenApp. In XenApp, since many users will be accessing the application from same XenApp server and if the application is writing some information in a common file, the last user will overwrite the information of previous user. Such things needs to be addressed in the development phase but since Development team is not aware such changes needs to be done at the end that calls for additional testing and so additional cost.
These are just the tip of iceberg. There can have lots of problem just because of less coordination between development team and operations.
In the current dynamic business scenarios, business is changing like anything and they need their changes to reflect on production as soon as possible. If changes are taking time, you are out of the business. Competition is huge. With old traditional methods, we cannot continue. Many companies like Amazon, Google have demonstrated that they can have multiple releases to production in a day. It has increased the expectation of the management to many folds. How these guys have made it possible? If they can deliver, why can’t we? It has many perspective and we all should understand what differently they have done to make it happen? Do they have some magic? Not at all….Let’s discuss it…
First step is to change the way we think, if they can do, we can too…
Second step is to think how to make all or most of the manual activities automated. Many manual activities that we do often can be easily automated like automated build, automated testing, automated deployments etc. We can have continuous integration and continuous delivery to make things moving fast. How it works? Let’s discuss it.
Developer have just finished work on the task he was working and now wants to do check-in. He has two options, one is to do build manually on the development machine and do some initial unit testing and then do a check in. Second is that on check-in, the already written unit test case will be run automatically and the build will be done on the independent machine. This second option is called continuous integration and with it, developers will get the results in few minutes and their build is also pristine. In the first option above, developer has to do the unit test themselves and they may miss few test cases and that can be costly at the time of the actual release.
In continuous delivery, the build files are continuously getting deployed in to the target environment on every change with proper approval workflow in place.
The essence of the continuous integration and delivery is maximum automation. For the management, it seems to be like clicking a button. Enabling continuous integration and continuous delivery is itself a time consuming thing as it sometimes needs scripting/programming. Writing such scripts at the time of release will put extra effort and time that might defeat the actual purpose of the automation. Then how to create them fast?
Here comes the main point behind DevOps. DevOps = Dev + Ops. Both the development team and operations have to have an excellent coordination and communication from the beginning of the software life cycle. This way automation can be implemented while development team is doing coding. As soon as the automation framework is created, development team can start using it in their day to day activity which will refine it to the maximum and at the time of actual release, framework is already in place and a click can make release a piece of cake. It will always deliver with great accuracy and predictability.
Mohd Aslam's Blog 