DevOps is hardly a new idea, but the need for truly embracing DevOps has never been greater. The term refers to...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
development and operations working together to meet business goals for software products and services. The call for DevOps is growing today for several reasons, one being that software organizations' departmental silos get quickly uncovered when using agile methodologies, which require business, IT and development collaboration.
In this tip, I'll explain why DevOps practices create productive software organizations and ways to put DevOps into action.
Since the beginning of commercial software, in healthy software cultures, development teams have been an integral part of releasing software. In a healthy software environment, everyone involved in creating the software is focused on releasing the software as painlessly as possible.
DevOps in action
On a healthy software team, people's roles overlap, information is exchanged among team members without need for artificial boundaries or gateways, and releasing the software is a happy occasion for everyone. Here is a scenario that shows how this continuum of roles can work.
All software starts with requirements of some sort. Maybe those requirements are called stories, or maybe the requirement is just an itch that needs scratching. There is usually a role on a software team concerned with creating requirements for the team to build. For the sake of convenience, call these requirements "stories" and call the role creating them "product owner."
As agile expert Alistair Cockburn said once, and Ron Jeffries has repeated incessantly, a story is a placeholder for a conversation.
The first conversation the product owner needs to have is with those in the developer role. On a healthy software team, the product owner and the developer will have detailed discussions about the story, its purpose, how it fits with other stories, etc. etc. Only when both product owner and developer understand what is necessary and what is possible for each story is it possible for the team to build the software correctly.
As development proceeds, it is often the case that dedicated software tester enters the conversation. A software tester will understand both the stories and the ongoing development work to manifest those stories, and will be constantly comparing the team's knowledge of the ongoing work to the greater environment of the whole application, as well as exercising the software in test environments that mimic production environments far more than developer environments usually do. As the stories become real, testers are thinking about the bigger picture and whether the particular details of this particular story will cause any issues for users or maintainers when the software ultimately is released.
There may be other parties involved in the conversation, perhaps a database administrator (DBA) or an architect or a project manager. Each of these roles may also have critical input into the development process.
So the product owner is discussing the implementation of the stories with the developer, and the tester is validating both the requirements and the implementation with the product owner and the development staff.
Bring in the system administrator
The role on the software team that maintains the product in production is generally the system administrator, or sysadmin. This role has the ultimate responsibility to make production code run on production hardware in a production environment. It would be silly to leave the sysadmin out of the software development conversation.
For one thing, the sysadmin needs to know the business case for the software, because the sysadmin is often the front line for user feedback, and it is impossible to evaluate user feedback with no knowledge of the purpose and context of the features of the software in question. Therefore, it is important that the product owner and the sysadmin have conversations about the ultimate purpose of the software being developed.
For another thing, the sysadmin must be aware of the architecture and implementation details of the software to be released. It is not unusual for a development staff to accidentally make an architecture choice that cannot be supported in a production environment. It is also common that software releases require data migrations that must be completed very carefully. It is also common that a software release will require upgrades of specific aspects of the production environment to specific versions of specific supporting libraries, frameworks, etc. Therefore it is critical that sysadmins have an ongoing discussion with developers about the implementation details of the software being created.
Software testers are the ones who know how exactly the software might fail. Sysadmins are the ones who have to deal with failures in production. An ongoing conversation between testers and sysadmins is highly desirable, because the sort of knowledge that testers have about potential points of failure can save a sysadmin hours or days of pointless work in the case of a failure in production.
In their daily jobs, sysadmins interpret business requirements; write code to automate their own processes; and investigate every kind of failure. Sysadmins already do the work of product owners, developers, and testers, just in a different context. It is a mistake to exclude sysadmins from the ongoing conversations necessary for software development to happen.
How to foster DevOps collaboration
Sysadmins are busy people. Here are some suggestions to include them in the conversation:
- A company-wide brown bag lunch policy is often helpful. The development staff can discuss their recent work with sysadmins, management, other teams, etc. etc. in an informal and relaxed way. This technique can be effective when more formal barriers may be in place in everyday work.
- Dedicated training for sysadmins just before releasing is effective. In this situation, the development team walks through the technical details of all the new features in the release with the sysadmin staff, having the sysadmin staff criticize the work. Leave time to make changes suggested by sysadmins! Interestingly, this sort of training is often conducted by the testing and QA staffers, who are generally working in test environments that resemble the sysadmins' production environments very closely.
- Have sysadmins involved in creating and maintaining dev and test environments. Sysadmins are smart people and often know tricks for maintaining particular kinds of computer environments that have escaped the notice of developers and testers. Besides making the developers' and testers' lives better, the sysadmin learns about whatever quirks and issues might be generated by the software being developed.
DevOps is old news
Healthy teams have been working in a DevOps sort of way for decades. The only thing new about the idea behind DevOps is that there is now a group of dedicated developers working to spread the word to those teams that are not so healthy.
Why Groupthink can be an Agile team productivity killer