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
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:
sudo su - jbossorg1
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:
sudo su - jbossorg
Copy labs-DATE.tar.gz to .
rm -rf jboss
If the content directory does not yet exist:
svn co https://cms.labs.jboss.com/<branch>/forge/portal-content .
If the content directory already exists:
If the wiki directory does not yet exist:
Unpack wiki content, that is, files that constitute the wiki pages
If the log directory does not yet exist, mkdir log
tar -xzf labs-DATE.tar.gz
After another successful release, team goes somewhere and drinks.