How have others solved the resourcing justification for Build / Release engineers? Based on number of supported developers? number of tools? number of deployments? are there base line ratios or other industry standards based on specific products or supported platforms?
It also depends on how mature your build, configuration, and deploy scripts are. A start up with nothing will require more resources than a mature set-it-and-forget scenario. We have one release engineer for a ~25 engineering group. Our build kits are very mature so we are focusing now on expanding automated regression testing as part of the nightly build (i.e. selenium grid).
Even with a set-it-and-forget scenarion, there is always something to work on or improve.
Sean
It will not only depend on the size of team , number of different types of builds running viz. daily, nightly , monthly etc. and also differnt kinds of streams running in production for which patches may be applied anytime. We were toltal 3 guys suppoting a team of 100+ developers subdivided to different teams working on indivudual modules . Suitation was very tight for us since we being occupied with some or other build issues.
Whatever be the size of team, I prefer to have centralized Build Team across the company since apart froom it helps in common toolset being used , support team in this scenario is big in size and knowledge sharing is pretty much easier there.
It will not only depend on the size of team , number of different types of builds running viz. daily, nightly , monthly etc. and also differnt kinds of streams running in production for which patches may be applied anytime. We were toltal 3 guys suppoting a team of 100+ developers subdivided to different teams working on indivudual modules . Suitation was very tight for us since we being occupied with some or other build issues.
Whatever be the size of team, I prefer to have centralized Build Team across the company since apart froom it helps in common toolset being used , support team in this scenario is big in size and knowledge sharing is pretty much easier there.
It also depends on how mature your build, configuration, and deploy scripts are. A start up with nothing will require more resources than a mature set-it-and-forget scenario. We have one release engineer for a ~25 engineering group. Our build kits are very mature so we are focusing now on expanding automated regression testing as part of the nightly build (i.e. selenium grid).
Even with a set-it-and-forget scenarion, there is always something to work on or improve.
Sean