|
---|
DFS Department
DFS delivery process
|
|
For every new DFS component delivery, following process should be applied. It
should involve different DFS Department roles (DFS Department Head, SEG members, DFS Department
projects managers or developers, DFS QA manager) and ESO project scientists or
representative end-users.
The delivery process must be preceeded by the integration
process. The delivery process must start only when the latter has been performed.
A delivery process encompasses following steps:
The delivery package preparation :
- the DFS
Installation Guide usually needs to be updated. The latest new issue must
then be archived into the DFS Department repository using the webcheck
tool.
- the dfsinstall script may also need to be completed. This dfsinstall
script is to be used for a complete new DFS release installation. See corresponding
dfsinstall
man page.
- the install-patch script, which is meant to install a DFS patch
only, also needs to be up-to-date. Use of this script is described in any
new Delivery Note: see
following instructions about how to create a DFS patch, and
following to get an example about the patch which updated DFS-4_4_1 to
DFS-4_4_5.
- the ipip script is a specific tool which installs a DFS Instrument
Pipeline. Each time it is updated, the related
man page must be archived via webcheck.
The appropriate DFS installation scripts must be included in the package delivered
to the mountain (install-patch if a patch is delivered, ipip if a new pipeline
release is to be installed, ...).
Go to top of page
The Delivery Note is the text file to be sent
to the mountain by email giving all detailed information about the new DFS patch
or release, plus the specific installation instructions to be applied by the mountain.
The Delivery Note file is named:
- for a patch: 'dfs-PATCH-x_y_z1-x_y_z2..txt' (e.g. dfs-PATCH-4_4_1-4_4_4.txt)
for a patch enabling to get DFS-4_4-2 from a previous installation of DFS-4_4_1).
- for a complete DFS release: 'dfs-RELEASE-x_y_z.txt'
It also has to be archived via webcheck by the SEG member responsible for preparing
the delivery package. It is then automatically published on the web: see here.
This file contains following information:
- DATE: current date by which the delivery package is described in the
Delivery Note
- TAR FILENAME: name of the tar file GENERATED BY: SEG member name
- ON: date of tar generation
- DEADLINE FOR ON SITE INSTALLATION: deadline for delivering the package
to the mountain
- WHERE TO BE INSTALLED ON THE MOUNTAIN: exact list of UTs, WorkStations
names, OS, VLT software at Paranal and La Silla where the package must be
installed
- IF PATCH, REQUESTED BY: mountain responsible name ON: date
- VCM DELIVERY NAME: dfs release or patch number: dfs-xx_yy_zz
Successfully tested by: testers names
- ON: date WITH: OS, VLT software version, ...
- GENERAL CONTENT: A general description in 2 or 3 lines (e.g. this is
the official delivery of the new Java OT)
- DETAILED CONTENT:
DFS-component-name1 and version: list/description of SPR, action items,
...
DFS-component-name2 and version: list/description of SPR, action items,
...
- RELEASE NOTES: release notes filenames (to be published on the web via
webcheck)
- PRE-INSTALLATION: pre-conditions to be addressed before starting to
install the delivery on-site
- INSTALLATION: detailed procedure describing step by step how to install
the package: account names, related UNIX commands, manual checks to be done,
... For a complete new DFS release, it's usually enough to refer to the latest
DFS Installation Guide.
- POST-INSTALLATION: any advice, check, suggestion to be applied once
the installation is complete
- DELIVERED TO THE MOUNTAIN IN DIRECTORY: Machine and location where the
package has been copied by SEG.
- PACKAGE FILES CHECK-SUM: for the Tar file, and every new installation
script, associated check-sum value
Go to top of page
In order to trace every delivery prepared by
SEG, a text file called 'dfs-delivery-history.txt' has also to be updated
and archived via webcheck by the SEG member responsible for preparing the delivery
package. It is then automaticly published on the web. See following
page.
This file gives an history of ALL previous deliveries (sorted by reverse chronological
order: last one first), while the Delivery Note is specific to one patch (or one
DFS release) only. The Delivery History file contains following information:
- The content of the Delivery Note (retrieved by Copy/Paste), except following
items since they are specific to the installation instructions:
- PRE-INSTALLATION:
- INSTALLATION:
- POST-INSTALLATION:
- DELIVERED TO THE MOUNTAIN IN DIRECTORY:
- PACKAGE FILES CHECK-SUM:
- plus the 3 new specific items:
- DELIVERED TO THE MOUNTAIN ON: date TO: list of names
- INSTALLED ON THE MOUNTAIN ON: date BY: list of names
- VERIFIED ON THE MOUNTAIN ON: date BY: list of names
The Delivery History file will then give, for every delivery, a complete description
of its content, and progress information about the way installation has actually
been performed on-site.
Go to top of page
A special meeting should take place just before
starting the actual delivery. Participants should be:
- the DFS Department head (if possible)
- the DFS QA manager
- the concerned project scientists (or representative end-users)
- SEG tester(s)
- SEG installer(s)
- the DFS Department developer(s)
Topics to be discussed:
- review the Release
Notes to present the main new features to end-users.
- present a summary of the SEG integration test results.
- present a summary of the on-site and acceptance test plans.
- give the current status of the installation preparation.
Minutes are done by the DFS QA manager.
A delivery package must be sent to the mountain
only if:
- the corresponding release/patch has successfully gone through integration
tests meaning that all new bug fixes and change requests have been successfully
tested.
- SEG testers have delivered corresponding Test Reports and presented main
results to the DFS Department head, and to the concerned DFS Department project managers
and to the QA responsible.
- the DFS Department head has given a final "GO AHEAD".
For packages sent to the mountain, the SEG member
responsible for preparing it must get progress information in order to accordingly
update the Delivery
History file.
These steps are fully described in following
link.
A special meeting should take place after
the delivery has been performed. Participants should be:
- the DFS Department head (if possible)
- the DFS QA manager
- the concerned project scientists (or representative end-users)
- SEG tester(s)
- SEG installer(s)
- the DFS Department developer(s)
Topics to be discussed:
- review the main issues detected during the installation, on-site integration
tests, and acceptance tests.
- get any feedback from end-users to improve next deliveries.
- decide what to do in short term: any action items ? is a patch requested
? if so, what is its content ? for when ?
Minutes are done by the DFS QA manager.
Go to top of page