some remarks on release-management

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

some remarks on release-management

helmut.denk
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 !
Reply | Threaded
Open this post in threaded view
|

Re: some remarks on release-management

hans_d
Administrator
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


Reply | Threaded
Open this post in threaded view
|

Re: some remarks on release-management

helmut.denk
hallo hans,

hdockter wrote
I'm not sure if it would make sense to provide a framework for  
complex release management ...
i think you are right.

IMO a possible use-case for gradle or ivy, is  'deployment-tooling'.

gradle can be used to support the implementation of
a deploy-tool, that runs on the target-systems. the
deploy-tool would be triggered from remote - for instance
by the integration- or release-build (startDeploy dependsOn
uploadDist) and pulls artifacts from repositories as defined
in a build.gradle.  

all deployment, i know so far, is 'push'. this would be
'pull' and it uses resolving in a quite natural way.
the resolved artifacts can be processes by the
target-system-specific package-manager or install-tool.

in case that something goes wrong during deployment,
the deploy-tool must manage a fallback ... such a thing
would definitely be a project of its own.

have a nice weekend