I used to work with DevOps specialists from few years. Mine experience is very positive. Nowadays I can’t imagine a new project without DevOps involvement. From the very beginning to the end and even later. This is one of persons that, as a Team Leader, I want to have by my side. Of course on each stage of project, their role is changing. Only one stays the same, the phrase: “Go to DevOps”.
General definition of DevOps
DevOps (a clipped compound of “development” and “operations“) is a software engineering culture and practice that aims at unifying software development (Dev) and software operation (Ops). The main characteristic of the DevOps movement is to strongly advocate automation and monitoring at all steps of software construction, from integration, testing, releasing to deployment and infrastructure management. DevOps aims at shorter development cycles, increased deployment frequency, more dependable releases, in close alignment with business objectives. (Wikipedia)
While starting the project I prefer to have DevOps present at some meetings. He will ask client about general deployment strategy and expectations. Probably he will make also some other general questions about monitoring, infrastructure, high availability and more. At this step there is no need to talk about much details, but knowledge about needs is important. From this point Programmer and DevOps start to cooperate. They are collecting knowledge about what will be done later.
As a first stage that comes me to my mind is always a CI. So then, “Go to DevOps” and let’s talk. This talk will be about environments, continuous integration during development, used branch modeling, deployment process. Initial arrangements will give possibility to write it down as Development Rules. From this point everybody know, how to work and what is the flow. In the meantime we need DevOps to set up ticket management for project, repositories (ex. on bitbucket), documentation space. I know that all tools that are required to continue work will be there.
During development there are many talks and agreements. We need to have concepts for logging, monitoring, configuration, databases, firewalls and security zoning, artifacts. DevOps will be that one, who will configure all this stuff at system and hardware side. All gathered knowledge in those topics, most probably will be part of Operations Manual at the end. This is how we can communicate and transfer knowledge smoothly.
There is not always a clear border between this what should be done by Programmer and DevOps, but most probably if you can not do something inside developers environment or click through button, then “Go to DevOps”. Close cooperation between those two, during all the time, will allow to avoid knowledge leaks. Personally I even prefer to have DevOps present at daily meetings.
Based on experience gathered during development, DevOps will be able to go ahead with final delivery even without Programmer present in process. Now starts much work with deployment and delivery to client’s environments. We need to remember that trip from development environments to production may be very long. Very often client want to test created software on few internal environments. Documentation about deployment and other is now transferred to client. May be need that client and DevOps spend some time together with adjusting environments to requirements. Based on agreement between software house and client, many possible actions may be taken: from basic support in deployment to complex configuration at production.
This is most dark side of software lifecycle. Here comes problems. There are all that things with bugs, SLA’s, night supporting. It should work like that: client call to support, they analyze problem and if find exact point in software, then come to Programmer with bug. That is the reason, why strong domain knowledge about system should be from the beginning near DevOps. Collection of Business Domain Knowledge and Infrastructure will give possibility to quickly react on problems. Well developed logging and monitoring systems should be very helpful. Role of DevOps is very complex during maintenance. They collect problems and communicate with client, so their communication soft skills are important. Most problems will be solved only by DevOps Team, however very often they will need to ask a Programmer about details of implementation.
Worth to cooperate with them
Close cooperation between Programmer and DevOps on all software lifecycle stages in very important. It should not be pragmatic, but proactive. Clear and often communication will avoid problems. Pair programming by those two will bring a lot of advantages. DevOps is not only that one with Linux secret experience called “administrator”. It’s present-day Renaissance Man who has to combine many soft and hard skills.
Posted in: Sortware