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.