Improving the release process
This page has been created after the feedback given by Andrew in his notes on how to
Improve the release process.
General thoughts
- We rely on the tools we use to build the middleware and track the changes: the tools contain all the information we need to create a release.
- The tools to build middleware and to track changes are different and there's no interface between them: information transfer from one to another has to be done manually.
- Manual steps can be automated but this requires effort.
- Motivation to automate the manual steps is low when the transition is supposed to be short. Moreover, the effort required to keep the release process going on leaves little time to work on automation.
- The tools we use are lacking very useful features, as documented in the following sections, and we are paying for this doing some extra work on our side (all the manual steps mentioned above).
- Effort should be put in improving the existing tools and not in writing scripts that at the end of the day are just workarounds of functionlity gaps in the tools.
- I personally feel comfortable with the manual steps but I understand this can be tedious for other people. Moreover the release process has been modified several times since last december as product teams were actually using it. We were adapting it after real use and automating things when the process is not mature yet is counterproductive.
Release manager tasks
The following features are currently missing in the tools we use and the release manager has to implement some steps manually:
| Feature number |
Description of the missing feature in the tool |
How it is done now |
Could be automated now? |
Comments |
| 1 |
ETICS: update of the project configuration once a patch is verified |
Manually editing glite_3_*_cert |
Use the ETICS CLI in combination with Savannah CLI to extract the information needed to update the project configuration |
Disadvantage: information is currently extracted from the Savannah patches that are filled manually and sometimes developers do not provide the correct information. I really think manual check is needed on this as far as savannah patches are filled manually. |
| 2 |
ETICS: changelog for a certain configuration (component, subsystem or project) is missing |
Log twiki pages glite_3_1_cert and glite_3_2_cert |
Use the Savannah CLI to generate the twikis. |
Disadvantage: same as before. |
| 3 |
Savannah: close internal patches once their relevant configurations are updated in ETICS |
Manually |
This could be done in 1) as an extra step. |
|
| 4 |
Documentation: Verified patch twiki |
Manually |
It could probably be created in the same way as 2). |
It's a kind of duplication wrt the Log twikis and this is probably true (see the motivation for this twiki in the comments of 2) in the Developers tasks. |
Developers tasks
The following features are currently missing in the tools we use and the developers have to implement them manually:
| Feature number |
Description of the missing feature in the tool |
How it is done now |
Could be automated now? |
Comments |
| 1 |
Savannah: creation of a patch |
Manually. Moreover developers need to find out what it is the 'delta' wrt the previous production version |
I'm not sure if this could be automated right now but it would be a complicated script using the ETICS and Savannah CLI. |
It's a pity this could not be extracted directly from ETICS since all the information you need is there: subsystem configurations used, diff between yum repositories, list of packages... Developers are suffering a lot from this manual step where it's very easy to make mistakes and forget things. This is only detected later on by Pablo when preparing the release and it needs several iterations until everything is coherent. It therefore demonstrates that the verification step we are doing within the Integration Team is not able to detect this type of inconsistencies. |
| 2 |
Savannah: attach the list of internal and standard patches also affecting your release |
Manually |
A script could query Savannah to check whether a patch was created for all the dependencies needed by a metapackage and attach the final list of patches at the end of the check |
This is difficult to track right now and I have created the Verified patch twiki to try to help at this point but I'm not sure whether it's really useful and people are actually using it. |
Release delivery tasks
| Feature number |
Description of the missingg feature in the tool |
How it is done now |
Could this be automated now? |
Comments |
| 1 |
ETICS: Repository creation. ETICS could create a repository out of a project configuration. All the packages needed are already present in the ETICS repository. |
release scripts |
It's automated  |
Maintaining the scripts is at a high cost since in the end we are implementing yet another tool when everything we need is already in ETICS (the packages are in the ETICS repo, it's just a matter of copying them in the right place and run a 'createrepo', right?). We run installation tests as well and this could be done in ETICS and included in the test report and save time in the preparation of a release. |
| 2 |
Savannah: Release notes creation. Product Teams are only including the release notes of their specific components and Pablo has to manually gather the release notes of the attached patches to make something consistent. |
Manually |
I think this is something that can't be automated now. |
If you want to produce a coherent set of release notes done in a general way as we do know, you need manual work. On the other hand, I think it's worth considering the possibility of maintaining release notes per package and keep this information in ETICS. This could probably allow for a full automation of the release notes creation. Otherwise, for a more general set of release notes, manual editing of the text is necessary and the person compiling the release notes really needs to have a good knowledge of the middleware and the operational issues affecting the infrastructure. |
Verification tasks
| Feature number |
Description of the missingg feature in the tool |
How it is done now |
Could this be automated now? |
Comments |
| 1 |
ETICS and Savannah: easy way to track the result of a deployment test |
Manually looking the test reports |
ETICS has deployment tests that could be run every time a metapackage is built. Just checking that the test is OK would be enough |
Maybe we can enforce in ETICS that it's not possible to lock a metapackage that fails a deployment test. |
| 2 |
ETICS and Savannah: easy way to check the completness and correctness of the information in a patch |
Manually |
Maybe but difficult |
Right now it's very difficult to know whether the right subsystem configuration has been provided for the released packages, if all the packages that have changed are present, if all the necessary patches and bugs have been attached... This relies on manual work. |
--
MariaALANDESPRADILLO - 06-May-2010
EGEE Web>SA3People>MariaAlandesPradillo>ImprovingTheEGEEProcess (2010-05-06, MariaALANDESPRADILLO)
EditAttachPDF
Copyright &© by the contributing authors. All material on this collaboration platform is the property of the contributing authors.