Version 12
Created by adamw on Oct 10, 2007 9:23 AM. Last modified by adamw on Oct 10, 2007 9:23 AM.

    Labs Package-building, Branching and Installation Policy

     

    1. From development to qa

    Two weeks before a release, a "feature freeze" is announced, and no new features can be introduced to trunk. If somebody has a strong need of developing a new feature at that time, he/she can do so on a separate branch and merge it with trunk after the release. The "feature freeze" will maintain until the release is done.

     

    The feature freeze lasts two weeks and during this period the system is tested by developers locally to find any "obvious" bugs. Also, an instance on a dev machine should run to see if there are no errors during long-running service.

     

    2. From qa to prod

     

    After this week, the trunk branch is copied to the qa branch (still trunk branch is frozen. Only bugfixes can be commited). Basing on the code in qa branch, a package is being created, with configuration matching almost exactly the one on the production server (all paths should be the same, except for the CMS address). This package is installed and again, left running for a week, for testing, on a qa server.

     

    Before installing the package, the CMS-prod branch is copied to CMS-qa. Any changes that have to be made to the CMS (updating configuration, copying new .jsps files from CMS-trunk) are done then.

     

    If a bug is detected, the code is fixed in trunk branch, merged to the qa branch and the package is re-built and re-installed (so basically the procedure goes back to the beginning of point 2).

     

    After the code is considered OK, the production configuration is updated to match that of prod, taking into account only the differences from the qa configuration:

    • CMS address change

    • host change in start/stop scripts

    • datasources change

    and again a package is built, which goes to production. The qa branch is copied to a new branch, with a name depending on the release number.

     

    Finally, the CMS-qa branch is merged with CMS-prod. At the same time, package is installed on production server.

     

    3. Building a package

    A package can be built on toad. The scripts are located on user's jbossorg1 account, in the directory /sevices/jbossorg1/package.

     

    To create a package, first check out the necessary code to the code subdirectory. Then, edit all qa configuration conf directory. Content of this directory will be copied to the code directory by the package-building script. Also, edit the start-stop scripts, which can be found in the scripts directory. They will be bundled with the package.

     

    If you want to also build a production package, add to the code-prod directory any configuration changes between the qa and production servers. Content of this directory will be copied to code after copying content of conf.

     

    Finally, run create-package.sh, which will create a labs.tar.gz file, which you can copy to a qa/production server.

     

    In short, you need to do the following:

    • ssh user@toad

    • sudo su - jbossorg1

    • cd package

    • cd code

    • svn up

    • cd ..

    • If this is a QA package, ./create-package.sh

    • If this is a production package, ./create-package.sh prod

    • scp labs-DATE.tar.gz SERVER

     

    4. Installing a package

    The default installation directory for labs is /services/jbossorg/labs. All paths are relative to that directory.

     

    • first remove the old jboss directory

    • make a checkout/update of content to the content directory

    • populate wiki content in the wiki directory

    • create a log directory

    • unpack labs.tar.gz --- that will create a jboss directory, and some scripts.

    • you are read to go, with running start-portal.sh

     

    So, speaking in shell language:

    • ssh SERVER

    • sudo su - jbossorg

    • cd labs

    • Copy labs-DATE.tar.gz to .

    • rm -rf jboss

    • If the content directory does not yet exist:

    • If the content directory already exists:

      • cd content

      • svn up

    • cd ..

    • If the wiki directory does not yet exist:

      • mkdir wiki

      • cd wiki

      • Unpack wiki content, that is, files that constitute the wiki pages

      • cd ..

    • If the log directory does not yet exist, mkdir log

    • tar -xzf labs-DATE.tar.gz

    • ./start-portal.sh

     

    5. Later

     

    After another successful release, team goes somewhere and drinks.

    1251 Views Categories: Tags: