222 lines
5.3 KiB
HTML
222 lines
5.3 KiB
HTML
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
|
|
<HTML
|
|
><HEAD
|
|
><TITLE
|
|
>Software Builds</TITLE
|
|
><META
|
|
NAME="GENERATOR"
|
|
CONTENT="Modular DocBook HTML Stylesheet Version 1.7"><LINK
|
|
REL="HOME"
|
|
TITLE="CVS Best Practices"
|
|
HREF="index.html"><LINK
|
|
REL="PREVIOUS"
|
|
TITLE="Change Propagation"
|
|
HREF="section1-chgpropagation.html"><LINK
|
|
REL="NEXT"
|
|
TITLE="Institutionalize CVS in the Organization"
|
|
HREF="section1-instprocess.html"></HEAD
|
|
><BODY
|
|
CLASS="sect1"
|
|
BGCOLOR="#FFFFFF"
|
|
TEXT="#000000"
|
|
LINK="#0000FF"
|
|
VLINK="#840084"
|
|
ALINK="#0000FF"
|
|
><DIV
|
|
CLASS="NAVHEADER"
|
|
><TABLE
|
|
SUMMARY="Header navigation table"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
CELLPADDING="0"
|
|
CELLSPACING="0"
|
|
><TR
|
|
><TH
|
|
COLSPAN="3"
|
|
ALIGN="center"
|
|
>CVS Best Practices</TH
|
|
></TR
|
|
><TR
|
|
><TD
|
|
WIDTH="10%"
|
|
ALIGN="left"
|
|
VALIGN="bottom"
|
|
><A
|
|
HREF="section1-chgpropagation.html"
|
|
ACCESSKEY="P"
|
|
>Prev</A
|
|
></TD
|
|
><TD
|
|
WIDTH="80%"
|
|
ALIGN="center"
|
|
VALIGN="bottom"
|
|
></TD
|
|
><TD
|
|
WIDTH="10%"
|
|
ALIGN="right"
|
|
VALIGN="bottom"
|
|
><A
|
|
HREF="section1-instprocess.html"
|
|
ACCESSKEY="N"
|
|
>Next</A
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
><HR
|
|
ALIGN="LEFT"
|
|
WIDTH="100%"></DIV
|
|
><DIV
|
|
CLASS="sect1"
|
|
><H1
|
|
CLASS="sect1"
|
|
><A
|
|
NAME="section1-softwarebuild"
|
|
></A
|
|
>8. Software Builds</H1
|
|
><P
|
|
>This section deals with the best practices for software builds. Build
|
|
is the process of creating the application binaries for a software release.
|
|
They are done in a periodic manner by the build teams to provide baseline
|
|
binaries for daily work. </P
|
|
><DIV
|
|
CLASS="sect2"
|
|
><H2
|
|
CLASS="sect2"
|
|
><A
|
|
NAME="section2-bebo"
|
|
></A
|
|
>8.1. Build Early and Build Often (<SPAN
|
|
CLASS="acronym"
|
|
>BEBO</SPAN
|
|
>)</H2
|
|
><P
|
|
>A variation of this adage has been around in the Open Source
|
|
community called "Release Early and Release Often" for quite some time
|
|
albeit for a different reason. BEBO helps a development team identify
|
|
issues that can arise from checking in the wrong files. BEBO will address
|
|
integration issues at the application level that might have slipped passed
|
|
individual developer builds. It will also improve the team morale when they
|
|
see a working version of the application.</P
|
|
><P
|
|
>Builds must be done on a regular basis. There should be a dedicated
|
|
resource(s) assigned to do the same. The entire project team must be
|
|
trained to view the daily build as an important activity and not as a chore.
|
|
Builds must be completed without any failures on a regular basis. Build
|
|
failures must be a rare event and should be treated with utmost seriousness.
|
|
The project team should ensure that successful builds are top priority on
|
|
their agenda. The seriousness can be emphasised by setting up a penalty for
|
|
breaking the build. </P
|
|
><P
|
|
>Each build can be tagged in CVS using a standard naming convention.
|
|
This can help developers checkout a working version of the entire system
|
|
from daily builds for local development. </P
|
|
></DIV
|
|
><DIV
|
|
CLASS="sect2"
|
|
><H2
|
|
CLASS="sect2"
|
|
><A
|
|
NAME="section2-automate"
|
|
></A
|
|
>8.2. Automate build Process completely</H2
|
|
><P
|
|
>Another key practice for software builds is to automate the build
|
|
process completely. The automation process must also include automatic
|
|
retrieval of the right source files from the CVS repository. This
|
|
ensures that the build process is completely repeatable and consistent. In
|
|
addition, the chances of a build with the wrong version of the application
|
|
source files are reduced to a large degree. </P
|
|
><P
|
|
>By automating the build process, the task of building often becomes
|
|
less burdensome. </P
|
|
></DIV
|
|
><DIV
|
|
CLASS="sect2"
|
|
><H2
|
|
CLASS="sect2"
|
|
><A
|
|
NAME="section2-ensurecheckin"
|
|
></A
|
|
>8.3. All necessary files must be checked-in before build</H2
|
|
><P
|
|
>This adage sounds trivial at first but this problem is very common
|
|
even with experienced development teams due to oversight. The problem of
|
|
oversight cannot be easily addressed since the onus is on the individual
|
|
developer to ensure that his or her file has been checked in. This practice
|
|
should be drummed into the team in the form of training and pre-build
|
|
announcements to ensure that the right version of source code is available
|
|
in the repository. </P
|
|
><P
|
|
>Automated build process as explained above will help in catching this
|
|
problem to a certain degree since they will automatically take the source
|
|
code from the CVS repository and perform the software build. Any missed
|
|
items will surface during the build process itself (makefiles etc.,) or
|
|
during the regression testing of the product (older version of the file
|
|
checked in). </P
|
|
><P
|
|
>A penalty based system can be setup to handle wrong check-in. Having a
|
|
kitty for a post project party to which each person who makes a wrong check-in
|
|
will contribute a fixed amount will act a good penalty system. </P
|
|
></DIV
|
|
></DIV
|
|
><DIV
|
|
CLASS="NAVFOOTER"
|
|
><HR
|
|
ALIGN="LEFT"
|
|
WIDTH="100%"><TABLE
|
|
SUMMARY="Footer navigation table"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
CELLPADDING="0"
|
|
CELLSPACING="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="left"
|
|
VALIGN="top"
|
|
><A
|
|
HREF="section1-chgpropagation.html"
|
|
ACCESSKEY="P"
|
|
>Prev</A
|
|
></TD
|
|
><TD
|
|
WIDTH="34%"
|
|
ALIGN="center"
|
|
VALIGN="top"
|
|
><A
|
|
HREF="index.html"
|
|
ACCESSKEY="H"
|
|
>Home</A
|
|
></TD
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="right"
|
|
VALIGN="top"
|
|
><A
|
|
HREF="section1-instprocess.html"
|
|
ACCESSKEY="N"
|
|
>Next</A
|
|
></TD
|
|
></TR
|
|
><TR
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="left"
|
|
VALIGN="top"
|
|
>Change Propagation</TD
|
|
><TD
|
|
WIDTH="34%"
|
|
ALIGN="center"
|
|
VALIGN="top"
|
|
> </TD
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="right"
|
|
VALIGN="top"
|
|
>Institutionalize CVS in the Organization</TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
></BODY
|
|
></HTML
|
|
> |