Being truly agile

In Uncategorized on March 29, 2010 by petrem66 Tagged:

The critical path to achieve agility as Service Provider includes having the capability to automate the application release process. Releases are scheduled interventions meant to promote enhancements to the web application. In order to keep the customer’s experience relatively stable, I don’t think such release needs to be triggered whenever a coder checks in a bunch of code into the repository. I’d rather want to accumulate a set of new features and release them in as a batch. But when we decide to promote the effort to do so must be minimal. There is a very neat concept promoted by Eric Ries (see continuous deployment) as part of Lean StartUp that I try to replicated
There are three aspects of the release process that I am interested in:
• Compiling, unit testing, and building components from the code base
• Provisioning servers, installing third party applications, configuring servers and deploying components
• System sandbox testing

Automating the compilation, unit testing, and build is main-stream. There are a lot of frameworks and platforms to compile, unit test, and build, but we do that by using Cruise Control with maven, and subversion. I admit that is a matter of preference rather than based on technical consideration. To do proper unit testing it is critical that source code have pair JUnits
Provisioning servers and installing third party applications in an automated manner is facilitated by most cloud providers that I know (Rackspace and Amazon WS) by exposing a Web service based interface. It is possible to decouple this aspect from the actual cloud provider using ANT scripts on two layers. The first layer or the façade exposes high level tasks such as ‘install.server’, the second layer exposes cloud provider related tasks such as ‘provision.server’ and third party application installation tasks such as ‘install.apache.2.3’. The cloud provider to install on, the third party applications to install, and the backup data to promote can be then set at the release level in a properties file. Note that our releases consist of up to 10 servers (Load balancers, web applications, db server, …). More on this one in a future blog
Sandbox testing is necessary to ensure that once the release is up and running it is of the best quality so that the customers don’t experience difficulties with the application and no data is lost. More on this one in a future blog


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: