Are they the same professionals divided only by the titles of positions they hold? Or there is something deeper?
Build/Release is only half of the story of DevOps. Continuous Integration and Continuous Delivery are necessary for DevOps, but there is the other half of the equation, the Operations side. DevOps is about removing the wall between operations and development, in order to release STABLE software (operations main concern) QUICKLY (developments main concern). Build/Release definitely helps with the Quickly portion, but it does not always address nor focus on the Stability portion of the equation (other than setting up stable, repeatable software releases). The other side of operations are left to Infrastructure groups. DevOps requires some build/release engineers, but it also needs the operations engineers in order to break down the walls.
Build / Release is a part of DevOps. Take a look @ ITIL Service Transition; the technical side is a portion of the overall solution. Build / Release generally does not pay attention to Change Management, QA, etc.
With regards to breaking down the walls, think of a company as a wheel. On the outside of the wheel (at the end of the spokes) you find the DBA team, SysAdmin team, QA team, Business group, Developers, etc. The DevOps is the center hub holding all the spokes together. All communication in one way or another channels through this hub.
Since Build/Release Engineer does just a part of what DevOps can manager, can he become a DevOps? Or can DevOps go for a Build and Release Engineer role – won’t that be reviewed as digression?
Some interesting point made here but you must remember that DevOps is a relatively new title for, at least in my experience, an old role. Its the industry is playing catch up and you should not judge the suitability of the candidate based solely on the job title. In this case the title DevOps is not that well established yet…at least not in the banking and telecommunications sectors. I agree that DevOps is the hub of the business but I have been a build and deployment engineer for companies where I had to liaise with all the stakeholders to ensure stable, quality releases. While ITIL has made clear distinctions with processes and the roles associated with them most organisations have not radically changed their internal job titles to match this. I recently interviewed for a DevOps role and I would say it was an exact match of my current skill set right down to the technologies used. If I were you I would continue read the description of the candidates role and not pay too much attention to the job title for the time being.
There are many, including John Allspaw and other DevOps big wigs, who would argue that one should not understand DevOps as a title at all and that organizations who do this are missing the whole point. DevOps is a movement of IT professionals who seek precisely to end the siloization of information technology. For many (and I’m still not sure where I come down on this) there would be no developers, operations people, QA testers, Release engineers or any other silo-ed position in a perfect world. Instead an IT organization would be a group of IT professionals increasingly becoming generalists each one owning the delivery of their code enhancements from start to finish.
DevOps is a very new term. However, ITIL Service Transition is nothing new; it’s been around for years. DevOps is nothing but an every day term for Service Transition. The problem is not that the role is new; the problem is that most companies don’t know what they want / need. A company does not want a CM / DevOps person until they have reached a certain size where having everyone do what they want is no longer cost effective. As most IT startups are the product of developers, the management making decisions tend to think like developers (iow: they hate process and believe it slows things down). I have interviewed for “DevOps” positions where they just wanted me to do Build / Repo Management. I have interviewed for “DevOps” positions where they just wanted me to be a business process release manager. It varies.
Different people are going to be drawn towards different aspects of technology, and will most likely shift around during their career. I can see DevOps embedding technologists into the various product teams, where they are closer to the development of the software. This way the expert in these technologies can help ferret out problems before they may appear later, due to assumptions made in the technology stack. The people on the team still focus on different technologies, but they share information more. The developers get to understand the technology from the “experts”, and the experts understand how the product is running on the technology from the ground up, and both groups start trusting each other more. Everyone wins. Companies cannot afford to have everyone as a generalist, it would be too much time to fix problems, or tweak the most performance from systems, or solve a difficult logic algorithm, if everyone only generally knew what was going on.
There will always be a place for Build/Release skills in software organizations. DevOps itself is too big (and too amorphous) to say there is a skill set that defines a DevOps engineer. I have seen companies with Build/Release creating software packages for the DevOps team to actually deploy, and I have seen companies where the DevOps group had a Build/Release specialist as part of the group. It really depends on what the company sees DevOps as, and what they are looking for.
Those who think IT is a generalized role don’t understand IT. IT works exactly like medicine. The only place you find one Dr. doing everything is in a small family practice. The only place you find one IT person doing everything is in a very small startup. You will never find a MD who is a brain surgeon, a heart transplant surgeon, and an OBGYN. The positions are too specialized. IT is the same; an Oracle DBA will never have the WebSphere performance tuning skills of a WebSphere specialist, who will never have the iOS / UI design skills of a mobile developer, etc.
If you want to gain an understanding of the concept of DevOps as a whole, read about ITIL’s Service Transition. Along with build / release technical tasks, start looking at change management. Figure out how to use your ticket system & version control system to generate a report with each build for what tickets are in each build. This is a great starting point to begin momentum from just build / release to overall devops.
The DevOps movements leaders have tried to capture the zeitgeist much in the same way as the agile movements leaders issued their manifesto. This happens when people are allowed the freedom to organise their own working practices which is why you tend to see this kind of thing in companies who’s managers facilitate their staff rather than dictate to to them. I think its a move in the right direction but like any movement…don’t always believe the hype..web 2.0 anyone 😉
As a CM Engineer, I help with change/release management, build & deploy tools, and environment management. In order to achieve this, my team helps break down the silos between DBA, IT, Test, and Development. We maintain the relationships and help facilitates changes from the development environment out to production smoothly and safely. IMO, CM is part of the DevOps movement and not a title. Together with other departments, we strive to have successful-stable deploys.
Release Engineering is a mix of VCS, build, config management and deployment engineering. With remnants of waterfall mentality, this role/team gets siloed out of core product development.
Devops is a movement, a methodology with tries to break the barrier, and boils down to dev taking ownership of code all the way into release. In smaller/leaner organizations, this is possible with each dev having operations skillset. Compare this to dev QAing each other or going ATDD.
In larger organizations, it’s not always feasible to have a unified skillset in every dev (add complex operational /integration /release /legacy needs). This is where integrated matrix teams of developers, release engineers and QA come into play, where each project/component team takes responsibility of developing and owning code, infra, quality, deployment all the way into production. Some multi component teams use Release Coordinators/Release Managers/Change Managers as well to gatekeep and integrate at a release level (on top of robust CI and ATDD practices).
A DevOps Engineer req these days essentially means a Release Engineer who integrates into Dev, and doesn’t resist product change as much (which is a core Ops principle).
Putting up siloed DevOps teams is a Buddha paradox (Buddha disputed idol worship, and now some idol worship him).