‘There is no present or future-only the past,
happening over and over again-now’
- Eugene O'Neill
I’ve been in the IT for 16 years and over the time I observed the same story – some companies try to either impose industry trends or to catch up with no success. Some ‘innovations’ doesn’t worth time spent on them, the other are real break-through. In this topic, I’m gonna talk about DevOps. There is nothing new in DevOps per se, and what we knew as a plain-old automation is now something more intelligent. In terms of business, the most important metrics are velocity, quality and time to market, therefore, methodology is an instrument – not the objective point.
Before we move forward, it worth to clarify, what is DevOps. It was said a lot, DevOps is a golden middle of Development and Operations etc., but in my opinion, it bridges the gap between technology innovation and business value. This is all about technology delivery to the business units (in terms of enterprise architecture) in timely fashion and ensuring it runs without interruption. In the official definition, there is nothing about rapid or continuous delivery/deployment (like in Agile), because it is related to automation and deep communication between relevant organizational units. In fact, it doesn’t matter what methodology your team or teams are practicing. At some point, it all come together to the stage of software release and communicating operational team for deployment and having not only user’s fast response but also operational team response and seamless integration is vital.
Embrace the future
None of the known methodologies can just be implemented. The worst mistake you can ever do is to blindly follow its practices, expecting immediate results. DevOps should be adopted and adaptation sometimes is a long, stressful and painful process.
The reason I recall Agile in this topic is because I heard too often ‘we already use Agile and continuous delivery, is this not the same to DevOps?’. Very often people (even on the executive level) confuse methodologies, their meaning and application areas. Aside from it, far not every organization wants go out of comfort zone, even if these measures are well-justified. Being change agent is a way not simple but very important role. You should be able to properly tie technology innovations, business value and the way it’s measured. The way a good change agent arguments DevOps for the business sounds not like: ‘we want to automate something for the sake of automation’. The right approach is – ‘we want to automate software delivery pipeline for the faster time to value and issues mitigation’. Overall, DevOps imposes performance-oriented culture in the teams, significantly improves communication, development cycle and release velocity, reduces recovery time and deployment failures. So, DevOps’s call is to answer the questions on how to:
- Automate build and testing processes
- Deploy and configure environments and keep the consistent
- Improve communication with the development team
- Monitor production, to be aligned with defined metrics and business goals
This might be a bit tricky, considering variety of teams (or business units in terms of EA), used technologies, security/compliance models and methodologies. The right tool set plays a key role in the process.
The process and tooling
The tools provide automation. Automation eliminates mistakes and waste. Automated release flow not only ensures consistent versions across assemblies/builds and deployments (using automated tests) but also makes a whole process more organized and predictable. Every change is traceable and reversible.
I tend to divide tool by relevant categories:
- Source code management (TFS, Git (GitLab, GitHub, BitBucket), Mercurial, SVN)
- CI Tools (TFS, VS Team Services, Jenkins, TeamCity, CruiseControl)
- Monitoring and analytics (Nagios, Zenoss, Zabbix, MS SCOM, Splunk, DataDog, Scout)
- Incident management (Jira, Service Desk+, Desk.com, Gemini)
- Project tracking (Jira, TFS, VS Team Services, Gemini, Trello, Bitrix24, Producteev)
Generally, the process looks like the one below:
Develop -> Build (+ Unit/Integration tests) -> Deploy -> Test (User acceptance) -> Promote (Upgrade)
What’s next?
In companies with implemented DevOps and relevant development culture you can observe better work organization on both, personal and team levels. Despite the fact DevOps is treated as a methodology, it does not replaces Agile (in any sense), even though it’s taking over much of the enterprise process and definitely not because some executives likes to say we’re agile. Some Agile methods can be used as part of DevOps, which is becoming more popular these days in the enterprise world. The point is, both methodologies perfectly works together for the sake of faster delivery, continuous integration, user response, which should lead to the continuous improvements, not only on the project but also embedding the organization level (methodology successfully applied at one business unit can be moved to another, with minimal amendments, embracing the enterprise).
Do not afraid of experiments, let the teams try, fail and learn. Do not micro-manage (but facilitate) the team(s), let them take the responsibility.
Remember, in the end, you don’t try, you can’t fail, but is this really you want to do considering tough competition?