Hello and welcome to my DevOps Dissection! My name is Ed, I’m a first year DevOps Analyst at QA Consulting and I am currently deployed at a specialist insurance firm within the FTSE 250 index. I’m here to pull apart and examine the reasonably new and growing field of DevOps.
The realm of Development Operations is quite new. It was born into our world during an AGILE conference in 2008 and started its teething during 2009 (i.e., it started screaming and clamouring for attention). Here in 2016 we now have a cynical child, questioning its surroundings and trying to grasp an understanding of how the world works. This cynicism is a force for good; IT practices must change. Traditionally, trying to get developers and operational IT staff to continually build, test, and frequently deliver small software changes has been like trying to perform open heart surgery with garden shears, jump leads and a car battery. You’re going to have blood everywhere from different IT teams fighting and some very angry stakeholders that wanted fast delivery, not a stagnant and dead business.
If DevOps were a celestial body you could consider it as an exciting new resource-rich planet orbiting the star of Information Technology. At its core we have a solid and defiant mass of cultural change, the surrounding mantel consists of rapid, continually flowing currents of communication and feedback, and last, the crust is a pleasant wrapping of technical implementation and know-how.
In theory this comes together to form a bridge across IT teams, aiding communication and collaboration.
Success is measured by rapid feedback mechanisms between developers, testers, management and infrastructure; fast delivery to different IT teams and the end user; and open integration, visibility and communication across every facet of development, testing, delivery and leadership. Often the means of achieving this success will involve incrementally adding automation and breaking cultural barriers between how different groups like to operate. It is an uphill march.
NB: There is a subtle difference between feedback and communication; feedback is more product-oriented (build failure, test failure) and what’s working, what’s not; communication is synchronisation between different people/teams working together.
Perhaps the most challenging obstacle is trying to persuade individuals to adopt new methods and technologies which will facilitate continuous integration, continuous delivery and work practice changes – these individual topics will be covered in future.
Unfortunately human nature is a stickler for stability and consistency, or at least what someone may believe is unwavering and offers security. This makes work flow advancements very difficult to implement as everyone loves the status quo. There is plenty I have resisted myself only to find that embracing new ideas and thoughts does truly satisfy the human desire to search for knowledge. The foundation for DevOps lies in establishing a river of cultural change. In due time I imagine I’ll be writing many more blogs posts about my own successes and failures at invoking this change.
Communication and Feedback
Simply the lifeblood of a high performing agile team. Silo’ed teams must be avoided as they lead to stagnant, toxic pools. Having two teams which are dependent on one another but operate separately is a recipe for resentment and malice. Ideally, different specialisations need to be glued together in order to develop T-shaped people (people who have a broad understanding of the various stages of the software life-cycle, while having a well-defined spike in a particular area). For instance if a developer were to be paired with a tester they may distribute knowledge between themselves leading to an understanding of each other’s roles. This will be a much deeper understanding than if the development team and testing team were split apart and silo’ed. This sharing of knowledge allows communication to take place and with a little technical assistance can be empowered where feedback can be absorbed and challenged face on.
The wrapping to all of this lies in the toys which this blog will be focussing on for the next few weeks. There is a plethora of technologies which allow the right flows of information and bring people together. Further than just communication we have all sorts of gizmos that allow for rapid, reliable, and repeatable build and deployment processes. The categories of these tools branch through: source code management, continuous integration, deployment, configuration management, tracking and monitoring, among others.
So here we are. This is my understanding of DevOps and the role it plays. We have 3 key components that combine into a formidable strategy for growth and improvement. Enforcing cultural change, opening up communication and using technology to help is the way forward for software development and promoting learning and evolution.
In my next blog I will be taking you on a journey through the different tools involved in the particular brand of DevOps I fulfil on site, beginning with Source Code Management!