Categories

A sample text widget

Etiam pulvinar consectetur dolor sed malesuada. Ut convallis euismod dolor nec pretium. Nunc ut tristique massa.

Nam sodales mi vitae dolor ullamcorper et vulputate enim accumsan. Morbi orci magna, tincidunt vitae molestie nec, molestie at mi. Nulla nulla lorem, suscipit in posuere in, interdum non magna.

Keep a check on the success rate of the builds on a regular basis ..

A build is critical to a software development program. Unless a regular build/installer comes on a regular frequency (we used to get a build every morning), it is difficult for the team to move ahead. The regular build incorporates the latest changes made by the development team, which includes both new code and defect fixes. As these are incorporated into the build, the team knows it has got the freshest code. If not for this regular build, the team would not know whether the different code changes being done by different developers have any conflict with each other, and the testing team would not know whether the defects that they are filing are over the previous defects that they have filed, or these are new defects. A situation in which a developer has already fixed a defect but that fix has not gone to the build and hence is not available to the tester, who in turn will keep on testing even though the code has been changed can get real messy. Hence, a regular build is necessary. But, there are many cases where this build can fail.
There can be dependency issues between the various elements of code which went into the build which causes either the build to break, or the application to not launch even though the build has been made. There can be infrastructural issues such as a failure of the machine to work properly, which can cause the process of build creation to become very slow, or even stop, or generate a built which has significant issues. There can be issues with networking, where the build machine has to pick up some components from another machine on the network and also work with the source safe repository, and any failure of these can cause problems in the build process. There can be errors on the side of the build engineer, because of which the build had some problem. Or there can even be software issues; we once had a case where a new version of the anti-virus caused the build process to slow down, and it was a real hard task to diagnose what the exact problem was – till that time, getting the builds out was very erratic and very frustrating for everybody concerned.
So, there can be errors at every point on the way. But you need to get a build out, and unless you are taking steps to ensure that you sending out alerts when the build is broken during the creation process, or the automatic smoke test detects some problem with the created build, you will end up losing a lot of time. Typically builds are created during the night (and our builds tool around 6 hours to get right), and with developers working till late at night and testers coming in early in the morning, the timeline for checkins, getting the build done, and getting it done right, was real tight. And of course, if there was any failure, it could screw up a lot of time for the entire team, and in some cases, lead to very heated discussions.
So, we did a lot of discussions on the build process, ensuring that there were a number of alerts, that there was smoke testing to do automatic launching of the created build, and the earliest QE on the scene who downloaded the build and tested it would send out a status on the build, with the build engineer on standby to quickly take care and do diagnosis if there are problems. And then we had the weekly status of any build failures. We would do a diagnosis of every build failure, whether due to equipment or human error, and then create a course of action to prevent these from happening again. In the minds of everyone was the cost of these failures, and effort spent to prevent it was well spent.

Leave a Reply

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>