357 lines
7.3 KiB
HTML
357 lines
7.3 KiB
HTML
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
|
|
<HTML
|
|
><HEAD
|
|
><TITLE
|
|
>Best Practices in Action</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="Institutionalize CVS in the Organization"
|
|
HREF="section1-instprocess.html"><LINK
|
|
REL="NEXT"
|
|
TITLE="Conclusion"
|
|
HREF="section1-conclusion.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-instprocess.html"
|
|
ACCESSKEY="P"
|
|
>Prev</A
|
|
></TD
|
|
><TD
|
|
WIDTH="80%"
|
|
ALIGN="center"
|
|
VALIGN="bottom"
|
|
></TD
|
|
><TD
|
|
WIDTH="10%"
|
|
ALIGN="right"
|
|
VALIGN="bottom"
|
|
><A
|
|
HREF="section1-conclusion.html"
|
|
ACCESSKEY="N"
|
|
>Next</A
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
><HR
|
|
ALIGN="LEFT"
|
|
WIDTH="100%"></DIV
|
|
><DIV
|
|
CLASS="sect1"
|
|
><H1
|
|
CLASS="sect1"
|
|
><A
|
|
NAME="section1-inaction"
|
|
></A
|
|
>10. Best Practices in Action</H1
|
|
><P
|
|
>The best way to explain the need for these best practices is by
|
|
putting together an example of a real world project scenario and show how
|
|
exactly will these best practices fit into the <SPAN
|
|
CLASS="QUOTE"
|
|
>"bigger
|
|
picture"</SPAN
|
|
>. Also, a lot of readers have told me that the sections on
|
|
<A
|
|
HREF="section1-branchmerge.html"
|
|
>Branching and Merging</A
|
|
>
|
|
and <A
|
|
HREF="section1-chgpropagation.html"
|
|
>Change Propagation</A
|
|
> will require examples for better
|
|
explanation. Listening to the readers is a Good Thing so I have
|
|
put together a particular project scenario and then create a series of
|
|
events to show how the best practices, if followed, would help is making
|
|
operations smoother. </P
|
|
><DIV
|
|
CLASS="sect2"
|
|
><H2
|
|
CLASS="sect2"
|
|
><A
|
|
NAME="section2-inception"
|
|
></A
|
|
>10.1. Inception</H2
|
|
><P
|
|
>Consider a software project where version 1.0 has just been put into
|
|
production and everyone is done celebrating. The next step is to start
|
|
working on the new features of the subsequent release. Also, the users of
|
|
the system have started to use it full-time and bug reports of various
|
|
levels have started to come in. </P
|
|
><P
|
|
> Before jumping into new enhancements or bug fixes, the best practices
|
|
for <A
|
|
HREF="section1-branchmerge.html"
|
|
>Branching and Merging</A
|
|
> should be followed. Few of
|
|
the important practices are <A
|
|
HREF="section1-branchmerge.html#section2-tagrelease"
|
|
>Tag each release</A
|
|
> and
|
|
<A
|
|
HREF="section1-branchmerge.html#section2-branchatrelease"
|
|
>Create a branch after each release</A
|
|
>. These practices will
|
|
effectively established two <SPAN
|
|
CLASS="QUOTE"
|
|
>"development environments"</SPAN
|
|
>,
|
|
one for regular enhancements and the other for bug fixes and minor
|
|
enhancements on the last release.</P
|
|
><P
|
|
>Let us assume that the release was tagged as
|
|
<P
|
|
CLASS="literallayout"
|
|
><br>
|
|
<TT
|
|
CLASS="literal"
|
|
>release_1_0</TT
|
|
><br>
|
|
</P
|
|
>
|
|
</P
|
|
><P
|
|
>Then the branch was created with the branch name
|
|
<P
|
|
CLASS="literallayout"
|
|
><br>
|
|
<TT
|
|
CLASS="literal"
|
|
>release_1_0_patches</TT
|
|
><br>
|
|
</P
|
|
>
|
|
</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="sect2"
|
|
><H2
|
|
CLASS="sect2"
|
|
><A
|
|
NAME="section2-dand"
|
|
></A
|
|
>10.2. Development and Delivery</H2
|
|
><P
|
|
>Now, we are ready for business. Let us examine the bug fixes and
|
|
enhancements track. Assume that there are three bugs of which two are of a
|
|
high priority that should be fixed right away (possibly within a week) and the
|
|
third can be delivered after some time (say after 4 weeks). In the
|
|
middle of this schedule there is a regular release scheduled in three weeks.
|
|
Considering that we have a busy month ahead, let us see how exactly we can
|
|
use the Best practices to ease the days ahead.</P
|
|
><P
|
|
>The timeline for the various release in the next month looks like this.
|
|
</P
|
|
><TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="programlisting"
|
|
> Fix Enhancement Fix
|
|
Today Release 1 Release Release 2
|
|
|_______|______________|_________|
|
|
Time -->
|
|
</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
><P
|
|
>We have two teams, one working on the bug fix branch and another team
|
|
working on the features for the next release on the main trunk. These
|
|
teams must make sure that they start out with the right version in
|
|
their sandbox.</P
|
|
><P
|
|
></P
|
|
><OL
|
|
TYPE="1"
|
|
><LI
|
|
><P
|
|
> The bug fix team will check out using the command line
|
|
</P
|
|
><P
|
|
> <B
|
|
CLASS="command"
|
|
>cvs checkout -R -r release_1_0_patches {project name}</B
|
|
>
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
>The team that is working on the next release will use the command line
|
|
</P
|
|
><P
|
|
> <B
|
|
CLASS="command"
|
|
>cvs checkout -R {project name}</B
|
|
>
|
|
</P
|
|
></LI
|
|
></OL
|
|
><P
|
|
> As soon as the bug fix team completes the two top priority bugs, they
|
|
will update, verify a successful build and commit their changes to the bug
|
|
fix branch using the command line
|
|
</P
|
|
><B
|
|
CLASS="command"
|
|
> cvs update -R -r release_1_0_patches {module name}
|
|
</B
|
|
><P
|
|
>The team should perform a build at this point to verify that the
|
|
update did not break any code on the branch. Once the build is successful,
|
|
the branch should be committed back into the repository. </P
|
|
><B
|
|
CLASS="command"
|
|
> cvs commit -R -r release_1_0_patches {module name}
|
|
</B
|
|
><P
|
|
><A
|
|
HREF="section1-softwarebuild.html#section2-bebo"
|
|
>Build Early and Build Often</A
|
|
> : On a daily basis, each developer
|
|
will check in code to CVS and to ensure sanity of code, daily builds on
|
|
the bug fixed branch will be undertaken by checking out from
|
|
CVS on a clean environment and completely rebuilt. These daily builds
|
|
can be tagged in CVS using the following naming convention </P
|
|
><P
|
|
CLASS="literallayout"
|
|
><br>
|
|
<TT
|
|
CLASS="literal"
|
|
>build_1_1_yyyymmdd : for the branch</TT
|
|
><br>
|
|
<TT
|
|
CLASS="literal"
|
|
>build_2_0_yyyymmdd : for the trunk</TT
|
|
><br>
|
|
</P
|
|
><P
|
|
>The regular process of build-test-fix is followed to make a version
|
|
ready for delivery. The tag will help developers checkout a working copy of
|
|
the latest build as and when necessary. </P
|
|
><P
|
|
> When the source code is released to the outside world, two practices
|
|
have to be followed. </P
|
|
><P
|
|
></P
|
|
><OL
|
|
TYPE="1"
|
|
><LI
|
|
><P
|
|
> <A
|
|
HREF="section1-branchmerge.html#section2-tagrelease"
|
|
>Tag each release</A
|
|
> : This ensures that the bug fix
|
|
release is tagged correctly and so can be traced out at a later point in
|
|
time if necessary.
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
><A
|
|
HREF="section1-chgpropagation.html#section2-mergebugfix"
|
|
>Merge branch with the trunk after release</A
|
|
> : This ensures that the bug fix
|
|
is merged back into the main trunk ensuring that all future
|
|
releases is a truly cumulative delivery.
|
|
</P
|
|
></LI
|
|
></OL
|
|
></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-instprocess.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-conclusion.html"
|
|
ACCESSKEY="N"
|
|
>Next</A
|
|
></TD
|
|
></TR
|
|
><TR
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="left"
|
|
VALIGN="top"
|
|
>Institutionalize CVS in the Organization</TD
|
|
><TD
|
|
WIDTH="34%"
|
|
ALIGN="center"
|
|
VALIGN="top"
|
|
> </TD
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="right"
|
|
VALIGN="top"
|
|
>Conclusion</TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
></BODY
|
|
></HTML
|
|
> |