Saturday, November 8, 2008

Build/Release Engineers will turn into Build/Release Consultants

As more and more software companies are adopting Agile development methodologies, the focus is shifting to Automated builds which require less manual intervention. Although Automated builds need less effort, they need a better initial planning and a solid release strategy.
So my point is here that future software industry will see more Release Consultant then Release Engineer. This way software companies will be further improving their productivity by automating their release management activities, anyway with the help of Release Consultants.
There is a free webinar from Electric Cloud, the build automation experts here.

Wednesday, November 5, 2008

What is the future of Build and Release Engineer? Part-2

To continue from my part 1, next answer is given by Stephan Schwab. He is International Software Technology and Agile Development Consultant. Thanks much for such a realistic views on Build/Release Engineering. I personally don't agree with Stephen's views but as a free blogger, it is my responsibilities to present facts as it is.

He says- I'm creating software since 1981 and have never felt any need for a dedicated build/release engineer. Regardless of the language used.

Don't confuse build/release with deployment/operations. For the latter you certainly want to have a dedicated team to fulfill these functions.

In agile development you should have an automated build that never - under no circumstances - takes more than 10 minutes to finish and doesn't depend on any infrastructure. So "building" is just a matter of checking out the code from the repository on a virgin machine and then you start the build. If you have to setup the environment, install a database or whatever else, then you are asking for trouble. Don't do this.

I've seen build/release engineers at clients who were just acting as a roadblock to developers. These guys usually make things complicated just to protect their job. That's not in the interest of the development team neither of the company they work for.

A good build is simple, requires no maintenance and everybody on the team is responsible to execute it multiple times a day to run all the tests before submitting new code. And developers should not sit on code either but integrate frequently and early.