Home

Welcome to the svnbuilding wiki!

Date	Version	Author	Description
30/Nov/06	0.2	Alec Clews <alec.clews@voga.com.au>	Initial Draft (copied from http://alecclews.pbwiki.com/SubversionBuilding)

This work is licensed under a Creative Commons
Attribution-ShareAlike 2.5 License<!—

—>.


Abstract

This paper discusses the issues that sourouding the building of
software in a controlled fashion. It presents key requirments and
concepts, and shows how the Configuration management change loop can be
completed by managing the build process from the Version Control
system, in this example Subversion and GNU Make.




A process will be presented that:

1. Ensures that all inputs to the build process are identified using a
   tag
   
2. Identifies all builds with the build environment in which the build
   took place
   
3. Places the build outputs under configuration management
   
   In addition possible areas of future development will be discussed,
   including the re-use of already built artifacts to speed up build time.
   
   !!What is Software Building
   
   When building software we take some input files, usually source code
   but they could be anything, and create some output files. Note that
   this paper does not discuss building code that is installed in some
   external environment such as a database.
   
   In many organisations the build process is given far too little
   attention. Common mistakes include
   
   
4. Not knowing what version of the code was used to build a specific
   output file
   
5. Not knowing what software tools and third party libraries where used
   to build software
   
   • Developers frequently supply production binaries created on their
     desktop PC’s
     
6. Not recording the results of the build for historical traceability.
   This includes information such as:
   
   • The specific options that where chosen for each tool used in the
     build
     
   • The software versions used in the build process
     
     In my many years of advising customers on their software process I am
     constantly disappointed by how many fail to see the value of an
     adequate build process or are not prepared to apply the effort to
     implement and maintain one. The sad fact is that failure to address the
     build process can break the entire SDLC and result in huge costs as
     people run around trying to answer the question “what’s different in
     production that made it break today?”.
     
     With the use of automated testing tools and frameworks the value of a
     automated build process is increased even more.
     
     There are other sources that talk about the mechanics of the build
     environment and creation of build scripts. I would like to talk about
     the interface between the build system and the configuration management
     system.
     
     For the purposes of this discussion there are three distinct build
     processes<br>
     
     
7. Sandbox builds that occur in a developer sandbox. The products of
   this build of not used outside the sandbox and are of no CM interest,
   other than they should not pollute the system build products
   
   
8. Integration Builds or Smoke Tests — to ensure that the software
   builds. It should be noted that unit tests are often invoked as part of
   this process
   
   
9. System builds. These builds are performed by automated processes and
   create builds for two purposes
   
   
   • Creating deployment artifacts — Creates outputs that is deployed to
     environments for some level of testing or for production release.
     
     
   • Providing a record of the build process for production audit
     purposes (NB Many current build systems fail in this requirement)
     
     !!! The importance of the Build Record
     
     From a configuration management perspective two of the key requirements
     are Accounting and Audit. These are not just academic concerns. We must
     be able to:
     
     
10. List all the artifacts and versions that compose a specific version
    of our product
    
11. Show which changes have been made to product version and that the
    work was carried our correctly.
    
    A full discussion of this is ouside the scope of this paper, however it
    is important that the build process does not break the audit trail of
    information between our released product and the changes that were
    developed in our various environments.
    
    In certain circumstances there may be legal ramifications if we are
    unable to supply this information.
    
    !! System Builds
    Ideally all system builds will be done in separate build environment
    distinct from the various runtime environments. This build environment
    should be subject to CM Change Control, e.g. a
    [http://alecthegeek.wordpress.com/2006/10/27/what-is-a-lightweight-ticket-process/|Lightweight
    Ticket Process].
    
    A system build must be done against a tagged version of the input files
    (a baseline).
    
    When the build is complete then consider placing the outputs from the
    build process under CM control. In subversion this can be done as
    follows:
    
12. Copy the input files onto a new ‘build’ branch.&nbsp; Consider
    having a ‘builds’ top level directory in your repository
    
13. Copy the source branch to the build branch — this is our input
    baseline
    
14. The build environment should used a predefined CONFIG_ID (set in an
    environment variable). This should relate to a change ticket
    
15. Generate a BUILD ID — It consists of the CONFIG_ID concatenated with
    the date&nbsp;YYYYMMDDHHMMSS
    
16. As part of building each output perform an <code> svn add
    &lt;outputfile&gt; </code>, on the build branch
    #&nbsp; TODO — test this
    
17. At the end of the build perform a svn ci. This will add the new files
    built
    
18. Apply two custom properties to each build file in Subversion
    a)The&nbsp; CONFIG_ID and b) the BUILD_ID
    
19. Close the build log
    
20. Add and check in the build log to subversion on the Build branch and
    add the BUILD_ID property
    
    !Further Work
    
    
21. Using other Build tools (e.g. Ant, CONS…)
    
22. Creating reports and release notes
    
23. Using other Revision Control systems such as Hg
    
24. 
    
    !Issues
    
    
25. Building source languages such as Java
    
26. Using tools other than Make (e.g. CONS, Ant)
    
27. Scaling the project up to include more files across multiple
    direcotries and more file types (e.g. yacc grammar)
    
28. Reusing built files across builds
    
29. Building for different platforms
    
    !References
    
    
30. [http://www.cmcrossroads.com/content/view/6778/134/| Mr Make]
    
    *
    [hhttp://www.pcug.org.au/~millerp/rmch/recu-make-cons-harm.html|Recursive
    Make Considered Harmful]
    
    *
    [http://www.martinfowler.com/articles/continuousIntegration.html|Continuous
    Integration]
    
    *
    [http://subversion.open.collab.net/articles/IntegratingSubversionIntoYourAntBuild.html|Integrating
    Subversion Into Your Ant Build]
    
    
    
    
    ! add more here