devops, and associated thoughts!

Here at REA, we have been firm believers in accountability of work, from the inception to delivery! To cement this idea, we instituted the concept of devops here some months ago, were a dedicated OPS person would co locate with the development teams for particular projects and be just like another developer. Conversely, a developer from one of the teams would colocate with the Operations team and experience being a systems administrator. The reasons were to get members of both teams aware of the fine grained issues and complexities that develop within the processes of development and/or deployment. We frequently rotated the personnel through this process to better spread the lessons learnt. Being an observer of this process, I have come to a few conclusions.

1. One person cannot be a ‘devops’ person.

It is not possible to have one person in a position where he/she is expected to do deployment and development while all others are expected to do only one of the above. The responsibility, and thats what it is, has to be shared across the team. It is the responsibility of the entire team to ensure that that the delivered product works in production, and not just one person.

2. It is a mentality, not a position.

It should not be marketed as position to slot one person in, or even rotate people through. A software developer who writes the code should be as concerned about his/her code working in production as he/she is in development. Definitely operations are more experienced with deployment and maintenance of products in production like environments, but that does not mean a developer should not base his software decisions before being aware of implications of deploying it in production, or be unaware of the status of his code after it passes quality assurance. The thinking behind devops is the critical bit of software development.

3. Operations need to be consulted early and often.

Operations are somehow considered as the team to call in last, when you have your product ready or almost ready. That in my humble opinion, is a fallacy. They need to be involved in every inception, every retrospective and every card kick off as any other team member. Their thoughts are most invaluable as they will look at a piece of work, not as whether it can be done, but whether it should be done based on the present state of production; whether there are some inherent dependencies that need to be resolved. Not only will this ensure that software developers will start writing software with production in mind, rather than their own laptop, but also the fact that this will spread the knowledge of state of production to people who might not have it to begin with.

devops is not a magical word that resolves our issues of deployment, dependencies etc, but it does get us started on the road of understanding that we are working to deploy to a production box, not our own laptops; and it is the responsibility of everyone involved to make sure that happens, and not just one lone person.

  • Great stuff, glad to see more companies doing this. One thing I wanted to share from my experience is that actually “one person can be a devops person”. In one of my previous jobs pre-devops we used to have “loans”, where one team member would be in loan to another team. While the idea was that people would volunteer on a monthly basis, it the long run the ones stepping up were always the same. Upon investigation we figured that this was due to some having a predisposition for cross-functional tasks while others favored getting down to the details in their own field of expertise. In that sense “one person can be a devops person”, and in fact it worked very well for us: each team would have one or two volunteers that would mix up with QA, PM, Devs and Sys and report and interface with the rest of the team without forcing others to do something that they probably wouldn’t have done well. Please note that I’m not saying others were allowed to hide in a corner and avoid interactions, but simply that they were absorbing external comms from an “internal face”, which maximized productivity. Hope it makes sense.

    • Mujtaba Hussain

      Hi Spike, nnI like the loans idea as well, but as you noted, if its the same person volunteering again and again, then the idea loses its charm. nnKeep fighting the good fight and keep reading 🙂

      • well, that’s actually what I was trying to argue, I don’t think it necessarily does lose its charm.nI can see why it doesn’t sound, and maybe is, as appealing, but as far as effectiveness goes it seemed to work pretty well for us. Some companies seem to struggle to apply devops mentality because it’s too much of a culture shock. Loans seem, if nothing else, a good stepping stone. Think of ambassadors if you prefer, you don’t send a whole country to familiarize with another, it’s the ambassador’s job to mediate and help both parties to see each other’s pros and cons by having knowledge of both.

        • Mujtaba Hussain

          I am wondering how far I can take the analogy of ambassadors! 🙂 I guess if you want to see a devops as an ambassador, then you have to give them the special right to deny deployments as well, if they don’t measure up to whatever metric is useful!

          • heh, good point, and actually yes and no. AFAIK Ambassador’s powers are fairly limited, he wouldn’t be able to deny a deployment – which is not desirable , but he would certainly be able to advise the government to do so – which is desirable. To bring it back to the real case, if an ops in loan saw something “dangerous” going on in a dev project he could bring it back to his team, discuss it and with that knowledge go up to the PM and raise the issue. Again, the point here is that the whole team doesn’t have to sit with the devs for that sort of cross communication to happen. Don’t get me wrong, not arguing against what you proposed, that’s certainly a more desirable condition, just saying it doesn’t seem necessary to ripe most of the benefit, think 80/20.