On Feb 19, 2008, at 7:38 PM, Sahoo wrote:
> Harsha,
>
> Release Engineering is a specialized role, just like development
> is. Some persons are exceptionally skilled to do both the jobs very
> well, but typically the same person does not (and should not) take
> up RE's responsibilities as well as developer's. When they do take
> up both the responsibilities, then they must distinguish between
> their roles. This does not scale well and is error prone. I expect
> environment used by RE to be much more controlled than developers'.
>
> Every module in your example is a separate maven artifact. I want
> RE to build and upload binaries for every module to maven
> repository - be it nightly, promoted or milestone builds. They
> can automate that process. I don't want to use a binary that is not
> produced by RE during my day to day development, let alone using
> such binary in the final product.
>
>
There are cases where two or more modules will be evolving
simultaneously.
This can be awkward to deal with in a central repository - single
maven repository
system. Here the better solution is to use hg: the developers
involved in the
concurrently evolving modules can share a parent workspace that is a
child of the
master workspace, and each can get updates as needed. But this only
works
for modules in the same workspace, and this may not always be the case.
In more complex cases, developers will likely have a need for
obtaining binary
modules that are not ready for RE checkin to the main repository.
How will
we manage this? I don't want every such case to go through RE.
Maven can certainly support local and remote repositories,
and there are a number of repository managers that support maven. It
seems that
we may at times require complicated sharing arrangements for multi-
module
development. In such cases, a developer may wish to publish an artifact
to an intermediate repository (not the master), and this is probably
best done
exactly the same way RE promotes an artifact to the master repository.
I also want to think about how much of REs role can be automated.
Many of us are
planning to automate as much as possible of our testing using Hudson,
and this
includes SQE and CTS tests. Once a module is known to pass all
required tests, it is
ultimately the developer that decides when a module needs to be updated.
The developer then works with the RE process to make sure that the
module
is updated, archived, and properly published to the appropriate
repository.
Other teams in Sun do this with hierarchical gate keeper
arrangements, so that
related modules are integrated at one level, producing artifacts that
may then be
pushed up the tree to a larger integration. The main things that RE
needs to do
is to make sure that all artifacts are properly tracked, and that all
artifacts in any
version can always be traced back to the exact source used to create
them.
In mercurial, this corresponds to the changeset ID in the mercurial
repository
used to create the artifact.
Ken.