Hi Helmut,
On Sep 18, 2008, at 12:39 PM, Helmut Denk wrote:
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 a lot for sharing this.
I'm not sure if it would make sense to provide a framework for
complex release management. But what definitely would make sense is
to provide a toolset for doing this (basically a release DSL) with
which you can assemble your company release policy.
One other aspect of release management might be to link together the
relevant configuration files on the host, the deployed artifacts and
the svn revision.
- Hans
--
Hans Dockter
Gradle Project lead
http://www.gradle.org
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
