Below I put some snapshots from Googl’e chrome release cycle presentation with some comments.

They originally planned this :

And got a lot of troubles with this cycle like :

• Long lived branches, which : Made supporting the branch (i.e. merging changes) more difficult as we drifted further from the trunk…
• Unpredictable release cycles, with date targets we could never hit, and….
• Engineers who were always in a rush to get their features into “this” release since we couldn’t make any promises about the schedule
  so they slightly change ( and simplify ) it to this 3 channel diagrams by making release shorter ( and reduce scope )

So they change traditional scheme to this one :

And then make it work in real life by cutting scope at release ( by disable features ) : Establish clear expectations (and engineering practice) to developers that any features not ready to ship at branch will be disabled (i.e. we only cut post branch, never add).

So it works fine for google guys and their rules are :

• The branch point is the end of our development cycle
• Features only get disabled post branch point
• Features should be engineered so that they can be disabled easily (1 patch)
• Only stability, security, and critical regressions can ever block a release

For me it’s looks fine for in-house development, but for me it’s big question how to apply same scheme for outsource development.

For those who like to use Azure instead of AWS :

1) Remove openjdk, gij
sudo apt-get remove openjdk-*;
sudo apt-get remove gij-*;

2) Install good one java powered by Sun
sudo apt-get install sun-java6-jdk

3) Install EC2 API
cd /home/abokov/

unzip ec2-api-tools.zip

4) Configure environment : add this lines onto the end of ~/.bashrc
#ec2 deal with stuff
export JAVA_HOME=/usr/lib/jvm/java-6-sun
# setting up Amazon EC2
export EC2_HOME=/home/abokov/ec2-api-tools-1.3-30349
export PATH=$PATH:$EC2_HOME/bin:
export EC2_PRIVATE_KEY=/home/abokov/keys/pk-XXX.pem
export EC2_CERT=/home/abokov/keys/cert-XXX.pem

export EC2_ACCESS_KEY_ID=***
export EC2_SECRET_ACCESS_KEY=***

You may check out how it works using ec2-describe-instances.

• Programmatic control via REST API
• Scalable data storage solution: Elastic Block Storage in Amazon AWS and CloudStorage in GoGrid
• Ability to assign external IP addresses
• Ability to grant root/administrator credentials
• Many options to configure the cloud cluster
• Windows and Linux support
• Web console for monitoring and management

So far, as cloud providers GoGrid and Amazon EC2 look very similar, but practical experience of using them in real-life projects helps us identify some unique features that can be important for specific applications – for highlighed features and bad points for both providers look onto GoGrid is out of beta on Grid Designer’s Blog