OmCollab deployment in BearingPoint IM Solution Suite

From MIKE2.0 Methodology

This article describes how OmCollab is deployed as part of BearingPoint's IM Solution Suite and how new capabilities are delivered through a continuous integration model. It also serves as a template for installing omCollab into other environments.

Contents 1 IM Solution Suite Technical Architecture 2 IM Solution Suite Deployment Architecture 3 IM Solution Suite Deployment Scripts 4 Operating Model 4.1 Key scripts 4.2 Execution order 4.3 Accessing the scripts 4.4 Deployment issues

IM Solution Suite Technical Architecture

Shown below is a high level view of the technical architecture of the IM Solution Suite and how omCollab is deployed in relation to other systems. Some internal knowledge management systems that make up the ImCollab ecosystem (BearingPoint's internal deployment of omCollab) are not shown in this model.

IM Solution Suite Deployment Architecture

This model shows how code is delivered through a continuous integration model. The software development and management process can be summarised as follows:

• The omCollab development approach follows a continuous integration process – based around “release early, release often”
• The code for testing on waterloo and in local development environments is extracted directly from subversion
• To deploy to production, code must be deployed from the waterloo test environment. This makes testing natural before deployment to production and prevents synchronisation issues with developers committing during the deployment process
• All hosts run the same codebase. Deployment processes are very similar, with localisation scripts taking care of host-specific tweaks during deployment
• Content backups are done automatically on a nightly basis for all environments
• A small administration team has deployment rights to these environments

IM Solution Suite Deployment Scripts

A number of scripts are run as part of the continuous integration process. This enables new versions of omCollab to quickly be deployed and minimizes the risk of deployment issues.

Operating Model

The main theory behind this is the following:

1. Developers fix bugs & add functionality using an IDE like Eclipse. They commit changes to the latest testing version of the codebase.
2. When a developer needs to test how the new code is doing on a live environment, he/she deploys the latest SVN contents on waterloo.openmethodology.org using the waterloo deployment scripts.
3. If approved by the release manager, the new code is then pushed to the production site (mike2.openmethodology.org) with a script on waterloo.
4. The MIKE2.0 administrator deploys the latest code from the local copy by:
   1. Executing the backup script
   2. Running the deployment script
   3. Checking that the site is up and running
   4. Deleting the local copy of the code that was transferred from waterloo.

Key scripts

1. checkout.[sh|bat] - is run on imcollab and waterloo to checkout the relevant code for deployment. The script must be edited to point to the relevant branch for checkout.

2. push_to_openmethodology.sh – used to push code from waterloo to openmethodology. Does this by copying code from ./root/svn-checkout

3. backup.sh – main backup script that backs up site

4. publish.sh - copies everything to the htdocs directory temporarily and executes the build script with localisation parameters from build.publish.sh. This is the script that is run to deploy omCollab in a linux environment (waterloo, mike2.0)

5. deploy.bat - copies everything to the htdocs directory temporarily and executes the build script with localisation parameters from build-publish.bat. This is the script that is run to deploy omCollab on imCollab.

6. build.php – main run script that installs omCollab software components. This is the same file which is used for local development build and on a windows platform

7. build-publish.sh – has localisation information (e.g. google analytics code, skin color) and the execution parameters for the build script. This script is modified based on local deployment. Note: There is some redundancy in this file and omconfig.php which should be refactored.

8.build.bat runs build.php. It removes the existing file system by default (but keeps database)

9.omconfig.php – script that holds the configuration parameters for installing the software components. A customized version of omconfig.php is specifically configured for each deployment environment that overwrites the default version that comes with omCollab. Note: There is some redundancy in this file and omconfig.php which should be refactored.

10. my_additional_build_processes.php – provides additional localisation parameters for imcollab and mike2.0). Different for each site. Note: There is some redundancy in this file and omconfig.php which should be refactored.

11.cleanup.bat – a script on imCollab that cleans up redundant files generated as part of the deployment process.

Execution order

Publish.sh is the top level script. This script is executed first:

1. Publish.sh copies over the build-publish.sh, build.php and my_additional_build_processes.php
2. Publish.sh calls build.php with parameters stored in build-publish.sh
   1. Build.php checks if additional build parameters are available in my_additional_build_processes.php, will use them if exists
3. Publish.sh cleans up deployment scripts
4. Publish.sh copies local version of logos over the default omCollab version
5. Publish.sh copies local version of omconfig.php over the default omCollab version

Accessing the scripts

You can use these scripts in your own environment. Scripts such as my_additional_build_processes.php will need to be localized. The approach has been designed so that build.php should be the same for each environment.

Deployment issues

If you have issues with these scripts, please post a ticket in trac