hello gradle, some remarks on release-management as i saw this is an item on gradle's road-map ... this may help to identify or exclude gradle requirements and/or to identify possible improvements in my companys release-management-process.
i think traditionally there are 2 different kinds of view on release-management: 'application-scale' and 'company-scale'. the 'application-scale' view focuses on the production-process (edit, build, test, deploy, config, run) of a single application or tool. this is also the view, that the open source community naturally has on release-management. if you are in a company, the 'company-scale' view comes up because an application or tool has to integrate into the company-specific landscape of applications and tools. integration is a difficault thing because you dont have control over applications and tools when they come from vendors and you sometimes dont even have full control over inhouse produced software. i think, for now the natural domain of gradle is 'application-scale'. but ideally gradle-builds will support the 'company-scale' in a way or help to unify both views in a far-off future. even if the 'company-scale' view is less important for gradle, i want to describe it first because it may help to understand some aspects of the 'application-scale' view, that i will describe in a later post ... and so, this is a draft description of my companys current 'company-scale' view on release-management: all of our 'inhouse' produced applications and tools belong to a release-context that is identified by a unique release-number, which is incremented in every release-cycle. we do a release-build once every month. so that 1 month is the length of our cycle. the release-build is technically managed by a team-member who has the role 'buildmanager'. the release is organized (timeline, communications) by a team-member who has the role 'release-manager'. 'buildmanager' and 'releasemanager' may be attached to the same person. currently our release-build builds all apps and tools regardless of the changes that happened during the cycle. applications or tools that want to be part of a release-build must be registered as release-items in a release-descriptor (release.xml). the artifacts that are produced by a release-build go through a quality-assurance-process which means, that they are deployed and tested on a production-identical system. if tests are ok, artifacts make a state-transition from 'integrate' to 'released' and are deployed to the production systems. patch-releases can be scheduled to fix important issues that are found during the monthly cycle. the production of a patch-release is very similar to the production of a regular release. apart from that patches have their own workspace and can do a partly build too (dont need to build all release-items). thanks you & have a nice day ! -- View this message in context: http://www.nabble.com/some-remarks-on-release-management-tp19550056p19550056.html Sent from the gradle-user mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
