Automating the build and deployment of legacy applications

The CWC experience

Steve JuddSystems Architect at CWC

Cable & Wireless CommunicationsFull service Telco (fixed, mobile, broadband, TV)Main businesses in Caribbean & Panama

Background

• N-tier application: ‘Liberate’

• Installed in multiple Business Units, on multiple environments

• Several releases are actively supported

The Application....

Challenges...

• 2 Version Control Systems:– Subversion for Java tiers– CMS for the Cobol code

• Each tier has its own build/deploy tools

• Many manual steps• Much co-ordination required• Dependency on highly

knowledgeable people• Equals risky, stressful, labour-

intensive releases• And finally…. CWC HQ is moving

to Miami this year

Objectives...

• Significantly reduce manual effort

• Simplify & streamline build & deploy process

• Remove dependency on VMS skills & highly knowledgeable people

• Migrate to one VCS• All to be completed by

June!

Approach

Some theory...• Useful books:

– “Continuous Delivery” by Jez Humble & David Farley

– “Jenkins - The Definitive Guide” by John Ferguson Smart

• Both contain useful ideas and approaches

However….• Daunting to apply these to a

traditional development shop...

• … with a large, complex legacy application

What to do, what to do...• Migration to a single VCS +

formally define the branching strategy

• Selection & adoption of a single tool to manage generation of application binaries

• Selection & adoption of a single tool to manage deployment

Our build/deploy pipeline...

Responsibility of Dev teamsUnit testingFunctional testingCommit to VCS

Compilation & generation of binariesRun any automated testsStatic code analysisGenerate Javadocs

Push binaries to Deployment server

Package binaries into environment specific deployables

Actual deployment mechanism

Version Control

Subversion...• Our VCS of choice• Why?– Reliable– Straight-forward to understand

& use– Good set of client tools– ...can even use under VMS!– Optimistic locking model

• Does mean we’ll be migrating our Cobol source though• Also need to change VMS development environment

Branching strategy

• Branch for latest development release (aka trunk)

• Branch for each major release (3,4,5 etc)

• Branch for each release build in a BU production environment

• 3 Subversion repositories: one for each application

• Standardise the branch naming convention

Subversion: lessons learnt• Merging – do it often &

check every merged file• Meaningful commit

messages• Using a VCS to store binary

libraries can be a bad thing• More small repos better

than fewer large

Building binaries

Binary generation• Jenkins is our Build Server of choice• Why we like it:

– Familiar technology– Integrates well with Subversion & Ant– Extensive library of plugins– Straight-forward to use/configure– Master/slave model– Ability to invoke scripts on a remote host

Plugins we use• Build Pipeline

– provides a view of upstream & downstream jobs

• Copy Artifact– Enables artifacts to be copied from another job– We use it a lot with Build Pipeline

• Text-findr– Searches for specified text in files & console output– Handy when scripts’ return code not sent back to Jenkins

Deployment

Our requirements• Complex deployment needs:

– Multiple Business Units– Each has a production environment + 1

or more UAT environments– Business Units often on different releases– Many system test environments

• Thus keeping track of what release where is important

• Management of Application Configuration

• 2 phase deployments• Able to deploy to Linux, Windows and

VMS

Why we chose DeployIt• It meets our requirements • Dictionaries for the configuration values• Handles Linux, Windows and VMS deployments• Release Dashboards• Composite packages for multi-app deployments• Custom plugin for 2 phase deployments• Only transfers packages that have changed