12 Nov 08 Continous Integration – A blast from the past

Although this didn’t happen a decade ago but still has been a good case for me to learn and realize how Continuous Integration brings value addition to our work.

As I recall it was like this when they were teenagers
Few teams working on different modules of same application, deployed together.
No build process formalized
No builds except for the ones that need major milestone deployments.
No feedback, reports, reviews etc.

So virtually there was no build eco system.

Which meant hideous amounts of communication, tons of trouble shooting, last minute show stoppers, And extermely unhappy end users/stake holders.

So what exactly was going wrong.

There was no Configuration Control i.e. No way to figure out the changes that will be part of the release and no controls to include or exclude them.
No Status accounting i.e. No feedback or status of anything as a whole product.
No management of Environment meant no one knew what hardware/software they were using and sometimes why?
No team work whatsoever meant no guided processes, reviews or tracebility of issues and pitfalls.

So virtually a release day was the doomsday!

It took some time for developers to realize that how important the following were.
* Configuration identification – What code are we working with?
* Configuration control – Controlling the release of a product and its changes.
* Status accounting – Recording and reporting the status of components.
* Review – Ensuring completeness and consistency among components.
* Build management – Managing the process and tools used for builds.
* Process management – Ensuring adherence to the organization’s development process.
* Environment management – Managing the software and hardware that host our system.
* Teamwork – Facilitate team interactions related to the process.
* Defect tracking – Making sure every defect has traceability back to the source

And after all it takes some time but the day to day flow looked like the figure below.

Build Management

Importantly
Developers are distributed on different locations in different teams.
There is an SCM team that takes care of the SCM activities i.e. Configuration Identification, Control, Build Management etc.
There is one single repository for all developers.
A process is defined for Product integration and its checked whenever some one checks in.
And hourly build is dont to check the sanity of the system with the unit tests.
A Nightly build is done with all full blown unit tests, coverage reports, Automated tests and installers and upgrades.
More over all of the above is shown on an FTP/HTTP site. FTP for installer/binary/archive pickup and HTTP for detailed view of builds/feedbacks etc.

All of the above meant strength and health of the build eco system. And more trust in the system that it will report failures along the way.

Tags: build, CI, continous, engineering, integration, scm, Software

12 Nov 08 Doing the Locale – Danmark

The following illustrates how to get the Number format working with a danish locale.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

import java.text.NumberFormat;
import java.util.Currency;
import java.util.Locale;
 
 
public class TestLocale {
 
 public static void main(String args[]){
 // Create a Locale for Danmark
 Locale DANMARK = new Locale("da","DK");
 
 // get the currency instance for this locale.
 Currency krone = Currency.getInstance(DANMARK);
 
 // Get a Number format for the locale.
 NumberFormat krFormat = NumberFormat.getCurrencyInstance(DANMARK);
 // A symbol for the currency
 String symbol = krFormat.getCurrency().getSymbol();
 // A double amount
 double amount = 10000.25;
// print it out after formatting.
 System.out.println(krFormat.format(amount));
 }
}

Tags: HOWTO, internationalization, Java, locale, Programming, Software, Software Development, tips, utils

12 Nov 08 That thing about CI – Continous Integration

Challenging Business requirements and the need for software development teams to remain agile and competitive while managing parallel development and releases requires a system which is adaptive to these demands.

Our approach to SCM enables unlimited and adaptable process models, which are ideally suited for parallel, distributed, and agile software development. Using state of the Art technologies from various vendors to automate processes such as branching, merging, build, and release keeps you a click away from software delivery.

The real matter then is the sanity of your application and that’s the challenge we all need to address. We can have cute products right of the shelf to get it up and going but the whole challenge lies in the statement “up and going”. It takes a ton of energy and effort to come up with the right process and the right tool. I have not seen alot of CI projects failing strictly. But I do have seen extra efforts into things that should not be really there. failure would then mean the amounts of efforts spent on doing not so trivial stuff and on the other end if you are spending alot of time doing the major flows then definately something is wrong.

Automation does solve most parts of the problems but things that really need to be taken care of to get it right in the sweet spot are the ones Martin Fowler described in one of his articles.

* Maintain a Single Source Repository
Keep everyone together, at the end of the day we all work together dont we?

* Automate the Build
Automation of the build helps you.

* Make Your Build Self-Testing
Self testing build tells you exactly what you did and what you broke. So I can come up with this statement to my Lead. “If I commit this, it might break alot of stuff”. Well Sir, try running the Unit Test, You will know for sure! But then again honesty on the test cases really doest matter!

* Everyone Commits Every Day
Typically in a Agile environment helps alot, and forces you not to break the build. Better organization I must say.

* Every Commit Should Build the Mainline on an Integration Machine
Sanity checking of your commits. So often we commit without realiazing that we break something else.

* Keep the Build Fast
I usually commit before leaving for home. It helps great deal when you get the feedback within 5 mins. kind of a benchmark but depends.

* Make it Easy for Anyone to Get the Latest Executable
Keep all the build results and one sharable place. We did that on one of the http servers some time back

* Everyone can see what’s happening
Importantly that all results are published for all of us to know.

* Automate Deployment
Deployment automation means that my buddy X on the other side doesnt screw up the server for even a 1 min. Only deploys when build successfull.

Hope this helps.

Resources:

http://martinfowler.com/articles/continuousIntegration.html

Tags: build, CI, continous, engineering, integration, Software