The responsibilities/activities I handled as release engineer can by broadly divided into three phases as follows:
Phase1: Pre-Build. This stage pertains to the activities expected to execute before starting the daily nightly builds.
Phase2: Nightly Builds. This is the phase starting from the just before code-freeze day till the build promotion day.
Phase3: Post-promotion. This phase starts after the promotion of the nightly builds to QA till the final release of patch to outside world.
| Table of contents sh |
1 Phase 1: Pre Nightly Build Activities 1.1 Responsibilities of new products
1.2 Responsibilities of already existing products
2 Phase 2: Nightly Builds 2.1 Nightly build activities
2.2 Nightly Build Tests
2.3 CVS, SVN and Other Source code management
2.4 SVN Branches
2.5 Source Code Control System(SCCS)
2.6 Shared Components
3 Phase 3: Post Build Activities |
Phase 1: Pre Nightly Build Activities
The activities in this phase can be broadly divided into two depending on the state of products, i.e. whether its a new product coming to sustaining or a product which is already supported by the sustaining.
Responsibilities of new products
For any new product to be supported by sustaining, its RE responsibility to set-up the build machine and build environment for the new product.
Following are the tasks RE execute in case if there is a new product in sustaining's kitty.
- Create the sustaining source code branch. RE work with the PDE team to get the PDE branch inside the firewall and making it available for the the sustaining engineer for checking-in their bug fixes.
- Identify all platforms on which the new product needs to be built and identify the systems for setting up the new build environment.
- Work/interact with lab team across the geography to get the necessary machine for the fresh build.
- Setup/install the build dependent soft-wares like CVS, SVN, BUILD_TOOLS, various compilation tools, Microsoft tools for windows platform builds on the new build machines.
- Setup HUDSON and necessary supporting tools for setting up the continuous builds new variants for GF 3.x
Responsibilities of already existing products
Before starting the nightly build activities it's RE responsibility to execute the below activities.
- Open the SCM branch for the checkins and notify the regarding the branch status.
- Verify if there is enough space on nightly workspace as well as on the build machines
- Update the configuration files with the build number, patch number and rpm build version correctly.
- Update the patch numbers for every fresh patch.Patch is the final deliverable from sustaining, hence care needs to be taken while updating the patch numbers.
- After the code-freeze date, lock the branch and update the patch READMEs with bug number and the description and check-in the READMEs
Phase 2: Nightly Builds
Nightly build activities
This phase basically involves the following RE responsibilities
- scheduling the nightly builds
- Notify the build issues to the team if there is any issues, resolve the issues.
- Making sure that nightly builds on all the supported platform go through successfully without any issues
The table below lists the Product against the currently supported Product tails and the platform on which it is built.
| S/N | Product | Platform |
| 1 | Application Server |
| Tails | Platforms | Distros |
| App Server 8.1_0 | - Solaris Sparc
- Solaris i586
- RHE Linux
- Windows
| The distros for 8.1_sust builds are divided into Enterprise Edition(EE) deliverable and non-enterprise platform(PE) bits. For Enterprise edition, RE has to build file-based patches as well as the package based patches.
For non-enterprise edition, RE has to generate only the file-based patches
The 8.1_02 builds the bits are delivered to the outside world in the form of:
- Files-based patches.
- Package-Based patches.
- JES5 based windows MSI patch.
Creating of JES5 patch for windows build is very resource and time intensive process and takes almost a day
Apart from the file and package based patches, RE is expected to generate and make available the bits in the form of bundles for QA.
|
| App Server 8.2_sust | - Solaris Sparc
- Solaris i586
- RHE Linux
- Windows
| The distros for 8.1_sust builds are divided into Enterprise Edition(EE) deliverable and non-enterprise platform(PE) bits.
For Enterprise edition, RE has to build file-based patches as well as the package based patches.
For non-enterprise edition, RE has to generate only the file-based patches
The 8.2_Sust builds the bits are delivered to the outside world in the form of:
- Files-based patches.
- Package-Based patches.
- JES5 based windows MSI patch.
Creating of JES5 patch for windows build is very resource and time intensive process and takes almost a day
Apart from the file and package based patches, RE is expected to generate and make available the bits in the form of bundles for QA.
|
| Sun Glassfish App Server V2.1.1 | - Solaris Sparc
- Solaris i586
- RHE Linux
- Windows
| For 8.2_Sust builds the bits are delivered to the outside world in the form of:
- Files-based patches.
- Package-Based patches.
For Glassfish V2.1.1 also apart from the file and package based patches, RE is expected to generate and make available the bits in the form of bundles for QA.
|
| Oracle Glassfish App Server V3.0.1 | - Solaris Sparc
- Solaris i586
- RHE Linux
- Windows
| For Glassfish V3.0.1, the bits are delivered in the form of closed network patches.
|
| Oracle Glassfish App Server V3.1.0_1 | - Solaris Sparc
- Solaris i586
- RHE Linux
- Windows
| For Glassfish V3.0.1, the bits are delivered in the form of closed network patches.
|
|
| 2 | Web Server |
| Tails | Platforms | Distros |
| Oracle Web Server 6.1 | - AIX
- Solaris Sparc
- Solaris i586
- RHE Linux
- Windows
| For Oracle Web Server 6.1, the final deliverable are in the form of
- File-based patches.
- JES based patches.
- Creating of JES5 patch for windows build
Apart from the file and package based patches, RE is expected to generate and make available the bits in the form of bundles for QA.
|
| Oracle Web Server 7.x | - AIX
- Solaris Sparc
- Solaris i586
- RHE Linux
- Windows
| For Oracle Web Server 6.1, the final deliverable are in the form of
- File-based patches.
- JES based patches.
Apart from the file and package based patches, RE is expected to generate and make available the bits in the form of bundles for QA.
|
|
| 3 | Proxy Server |
| Tails | Platforms | Distros |
| Oracle Proxy Server 4.0.1x | - AIX
- Solaris Sparc
- Solaris i586
- RHE Linux
- Windows
| For Oracle Web Server Oracle proxy Server 4.0.x, the final deliverable are in the form of
- File-based patches.
- JES based patches.
Apart from the file and package based patches, RE is expected to generate and make available the bits in the form of bundles for QA.
|
|
Nightly Build Tests
As part of nightly build, RE is expected to execute certain tests against the fresh builds. Its RE responsibility to see to it that the fresh builds pass these tests with the expected results. These tests are differ for every products. Below is the listed that RE run against the products.
| Product Tails | Nightly Tests |
| Application server 8.1 and 8.2 | - PE Quick Looks DEBUG (against DAS)
- EE Quick Looks DEBUG (against remote instance)
- PE Quick Looks OPTIMIZED (against DAS)
- EE Quick Looks OPTIMIZED (against remote instance)
- SQE Smoke Tests OPTIMIZED (against DAS):
- ANT-CORE Tests OPTIMIZED:
- OPTIMIZED CTS Smoke Tests:
|
| Glassfish V2.1.1 | - Quick Look Tests on the PE Installer
- Smoke Tests on the PE Installer
- Quick Looks on GlassFish EE (Clustering) server image
- Quick Look Tests on the EE Installer
- Smoke Tests on the EE Installer
|
| Glassfish V3.0.1 | - Quick Look Tests on the Installer
- Smoke Tests on the Installer
|
| Oracle Glassfish Communication Server V1.5 and V2.0 | - GlassFish Quick Looks on server image
- Smoke Tests on server image
- Installer CTS Smoke Tests
- SailFin QL (cluster) Tests
- Functional Test
- SailFin Smoke Tests
- GlassFish Clustering Quick Looks on server image
|
| Web Server 6.1 And 7.0 | |
CVS, SVN and Other Source code management
RE maintain the following CVS branches.
- SJSAS82_FCS-SUSTAINING_BRANCH
- SJSAS81_FCS-SUSTAINING_BRANCH.
- WebServer70_u11Rtm_Branch
- S1WS61RTM_SPI_AS81_Branch
- SGES21_FCS-SUSTAINING_SECURITY_BRANCH
- SGCS15_FCS_SUSTAINING_BRANCH
- SGCS15_FCS-SUSTAINING_PRIVATE_BRANCH
- SGES211_FCS-SUSTAINING_PRIVATE_BRANCH
- SGCS20_FCS-SUSTAINING_PRIVATE_BRANCH
- Proxy40RTM_Branch
SVN Branches:
- http://mercurial.us.oracle.com/svn/glassfish/sustaining/trunk/3.0.1-1
- http://mercurial.us.oracle.com/svn/glassfish/sustaining/trunk/3.1.0-1
Source Code Control System(SCCS)
Other than maintaining the CVS and SVN source code branches RE is also responsible for maintaining the build scripts which are crucial for any builds.
These are maintained in Source Code Control System(SCCS)
RE maintain the build scrips, build configuration files of the below listed products
- AS 8.1
- AS 8.2
- AS 2.1.1
- Sailfin Communication Server v1.5
- Sailfin Communication server v2.0
- WebServer 6.1
- WebServer 7.0
- Proxy Server 4.x
Shared Components
Below listed shared components are built and staged by me
| Shared Component | RE responsibilities |
| ORB | - Maintain the build infrastructure including the machine and the build environment
- Build and stage the ORB
|
| NSS | - The NSS is delivered to Application server in different formats. For GF v2.1.1 its in the form of bundled jars where as for other application server the bits are staged as directories. RE responsibility is of packaging the NSS bits as per the products requirements.
- RE responsibility in regards to NSS pertains to following tails of application servers.
- AS 8.1
- AS 8.2
- AS 2.1.1
- Sailfin Communication Server v1.5
- Sailfin Communication server v2.0
- The NSS bits need to be packaged per platform and spacial care needs to be taken to support 64 bit support.
|
| JDK | - Similar to NSS, the JDK s delivered to Application server in different formats. RE responsibility is of packaging the NSS bits as per the products requirements.
- RE responsibility in regards to JDK pertains to following tails of application servers.
- AS 8.1
- AS 8.2
- AS 2.1.1
- Sailfin Communication Server v1.5
- Sailfin Communication server v2.0
|
| MQ | - MQ bits are staged by RE at the external staging location.
- The bits are staged for three tails of applications servers listed below:
|
| Load Balancer Pluggin | - RE responsibility is to maintain the CVS branch of the LB, build infrastructure, machines, build environment and stage the load balancer.
- LB is built on 4 different platforms for the following applicaiton servers:
- Load banlancer is built on following platforms
- Solaris-Sparc
- Solaris -i586
- Windows
- Linux
|
| pwc1.2 | - This shared component is built for Web Server.
- RE responsibility is to maintain the build infrastructure, build environment for building PWC. It also includes staging the component in the external staging location(/share/build/component
|
Phase 3: Post Build Activities
After couple of stable nightly builds, on or before the promotion date RE is expected to execute the following activities. 1. Do a sanity on the latest nightly builds.
2. Verify if there is enough space on the disc to copy the promoted builds.
3. Promote the builds to QA.
4. Verify if all the bits are promoted.
5. Once the QA gives his approval the patches need to be pushed to PST pipeline.
6. Verify the patch READMEs before releasing the patch.
7. Finally RE has to clear the requester hold off the patches which were submitted to the PST pipeline.
No comments:
Post a Comment