Build and

automated builds

www.scmGalaxy.com
sG

Author: Rajesh Kumar

[email protected]

scmGalaxy
Build script
www.scmGalaxy.com

 A build process is expected to help create a single

integrated unit that can be deployed on a target
environment
 A build process can be a sequence of steps that helps
in creating a unit
 Compilation - javac
 Integration – jar
 Creating one unit – war
 Deploy – put the war file into a particular directory
 The need for a build script arises once there is a need
to build the unit multiple times and by multiple
people
 Defining a build script to take care of the sequence of
steps helps in faster build process and most
importantly the ability to standardize on a build and
deployment strategy across the team

scmGalaxy
Manual build process
www.scmGalaxy.com

 A manual build process is the one where each

individual is expected to go through a set of steps
based using his or her memory or a documented
steps
 With time parts of steps will get side-stepped
 More often than not parts of the code will be
deployed rather than the whole
 A properties file change and the related java class
change should be released together. One without the
other will not be of any use
 A manual build by a developer or a CM is too risky for
the project
 Even addition of new steps (like adding code guards
using a script before compilation) cannot be done
unless a script is used

scmGalaxy
Build script
www.scmGalaxy.com

 Each software platform will provide a way to write a

script and invoke a sequence of build steps
 Unix shell scripts, make files, windows batch files etc
can be used to define a build script
 A framework / tool like ANT, helps in abstracting the
script from a platform dependency and use simple
XML file to define the build script
 Interestingly ANT itself is only a XML notation, that
defines the sequence of steps. The steps themselves
rely on the code base, framework binaries, SDK
binaries etc.
 In summary using any suitable syntax a build script
should be defined. The script itself should automate
the sequence of steps that needs to be executed to
create a single unit of software

scmGalaxy
Notes on build script
www.scmGalaxy.com

 Choose a language that can be used in multiple

platforms (very important for a java project)
 Ensure that as many steps are automated. Begin with
a full clean up and allow full build and deployment to
the server
 Automate even server restart to increase developer
efficiency
 Each build should ensure that it recompiles all
classes and optionally fetches latest code from the
repository
 Stale references to others code is the most frequent
offense among developers. So use the build script to
enforce some discipline too

scmGalaxy
Notes on build script
www.scmGalaxy.com

 During peak development, the number of builds and

changes to a particular piece of code on a developers
machine can be as high as 50
 If the developer is made to build and deploy as many times
even for small changes like JSP, simple Java class change
then the productivity of the developer can be affected
 While writing a build script, one needs to take care of small
short cuts that can help in a faster build and deployment
 Deploy only HTML and JSP
 Deploy only compiled java classes
 Do only a restart
 Deploy only properties files
 This is not a default option and one should not spend time
at this in the beginning. This is a step more relevant to
iterative improvement of the build script

scmGalaxy
Environment and build
www.scmGalaxy.com

 The unit created by the build is dependent on the

environment it will run in
 A build is expected to modify environment related
dependencies before it creates a integrated unit
 The build script can also modify the environment
before it deploys the unit
 It is important to keep in mind the various
environments in which a build will execute the parts
of the environment that needs modifications during a
build
 Typically a environment consists of
 A application server
 A web server
 A database

scmGalaxy
Environment and build
www.scmGalaxy.com

 A build could affects all parts of the environment

 App server – deploy the ear file
 Web server – deploy web assets
 Database – deploy DB scripts
 A strategy needs to be evolved to ensure that the
automated deployment (or manual) affects all parts
of the environment
 Recreation of the DB at regular intervals, redeploying
web assets (images) with each deployment is an
important practice to test the code sanity
 Ensure that the build script takes care of tagging,
building and deploying all related parts of a project
 How often each of them should be refreshed differs
from case-2-case, but, the build script should be
capable of managing all deployments to all parts of
an environment
scmGalaxy
Build script and dependencies
www.scmGalaxy.com

 Once an environment has multiple constituents it is

important to understand the inter-dependencies
between them
 A java code base often is dependent on the table names and
column names
 A UI image path defined in a JSP is dependent on the existence
of that asset in the web server
 The whole java code base depends on the existence of a data
source defined in the app server
 More often than not parts of this will change without
the other even being informed of the same

scmGalaxy
Non-related changes that break the build
www.scmGalaxy.com

 Case 1
 DBA makes changes to the DB model based on the requests
from the module leads
 But the code in the module will not need this change for another
week
 Case 2
 DBA modifies a column name of an existing column to resolve a
review comment
 The existing java code needs to reflect this change
 Case 3
 The Driver for a DB connectivity has changed
 The app server configuration needs to change

scmGalaxy
Non-related changes that break the build
www.scmGalaxy.com

 In all these case, a part of the environment has

changed and the rest of the application get affected
 The key question is how can the build and release
process be synchronized to reduce impact
 The answer is in bringing about a convention and a
team level practice that when followed can reduce
the impact
 First understand the individual parts and their dependency
 Measure risk of stale data
 Synchronize the deployments

scmGalaxy
Understand dependency
www.scmGalaxy.com

 First understand the dependency, the risk and the

level of impact
 A web asset if not refreshed only results in an old image being
shown – relatively low impact in a dev phase
 A DB column change can affect the way in which the java code
accesses the DB and can result in an exception – high impact
 A new DB driver will result in a change in the data source
configuration. The whole application needs to be tested – high
risk

scmGalaxy
Synchronize the deployments
www.scmGalaxy.com

 The answer to all problems is in synchronizing the

deployments
 Strategy 1 - Full deployments each time
 Strategy 2 - Full application deployment and partial deployments
of dependent systems
 Strategy 3 - Full application deployments and dependent
systems deployed at regular intervals

scmGalaxy
Synchronize deployments -
Strategy 1
www.scmGalaxy.com

 Full deployments each time

 Here the DB or other dependent systems are rebuilt with
each code deployment
 Pros
 The dependent systems and the code base are refreshed each time and
errors can be caught very early
 Reference to stale column names, images etc can be easily discovered
 Stale data is also refreshed each time
 Complete automation can be achieved
 Cons
 Needs thorough testing and automation of functional testing to ensure
that the breaks can be discovered early
 Frequent builds can lead to high code breaks because the code cannot
change at the same pace as a DB
 Team discipline needs to be very high with respect to code
modifications and modifying the dependent assets
 Build and configuration management team has too many tasks to work
with

scmGalaxy
Synchronize deployments -
Strategy 2
www.scmGalaxy.com

 Full application deployment and partial deployments

of dependent systems
 The partial deployments to the dependent systems
can be controlled and be executed on a need basis
 The team decides which script needs to be deployed
and only those scripts are deployed with each build
 Pros
 The partial deployment helps in better scheduling of code
modifications
 Testing can be targeted at a particular area where the highest
amount of change has been delivered
 Cons
 Automation cannot be achieved due to human decision
intervention
 Can lead to erroneous code being used till such time the new DB
changes are introduced
 Bugs and errors are caught late in the cycle
 Coordination between the team could be a weak point
scmGalaxy
Synchronize deployments -
Strategy 3
www.scmGalaxy.com

 Full application deployments and complete

deployment of dependent systems at regular
intervals
 In this strategy the dependent systems is refreshed
at regular intervals (every fortnight, ad-hoc but well
announced dates)
 Pros
 A blended approach and helps teams schedule code
deployments better
 The fact that the dependent systems are rebuilt regularly
ensures that the bugs will surface with each rebuild
 Automation can be achieved.
 Cons
 Code breaks will be discovered late but it will be discovered
 Needs automation of functional test cases

scmGalaxy
Frequency of builds
www.scmGalaxy.com

 A build essentially brings an integrated unit of code

and deploys the unit into an environment
 It is the first point of integration where compilation
errors will automatically be discovered
 With a higher amount of integration and integrated
builds the risk of integration level bugs will get lower
 Typically an integrated build can expect to find the
following types of bugs
 Method signature incompatibility
 Incorrect reference to column / table names
 Some amount of testing can help in discovering flow continuity
bugs

scmGalaxy
Frequency of builds
www.scmGalaxy.com

 The frequency of builds is dependent on the phase of

the project
 During the initial phases, code incompatibility is
definitely expected, so the builds can be less
frequent and sometimes not even required
 Gradually the team begins to use each others code
and the inter-dependency increases between
individuals and modules
 Initiate a weekly build and then increase it to 3ce a
week in a short period of time
 A daily build and a continuous integration build can
be a goal once the build process stabilizes and lesser
breaks occur

scmGalaxy
Environments in a project
www.scmGalaxy.com

 How many environments should a project have?

scmGalaxy
Environments in a project
www.scmGalaxy.com

 No correct answer. But it is a function of the various

types of audience that the project needs to cater to
 For a project that is being developed and it is in the
dev phase, the various environments could be
 Client
 QA environment Internal testers
 Integration unit for developers
 Developer
 For a project that is on production
 Production
 Production-like (can be dormant)
 QA for production
 A QA environment per release being worked upon (usually 1 or
2)
 Integration environment
 Developer
 Understand the need for a new environment and how
to decide on the final count
scmGalaxy
Environments in a project
www.scmGalaxy.com

 Each environment should have a separate app and

web server. It needs to have a separate DB instance
 The integration environment should be machine on
which the build itself is executed
 It helps in ensuring that any target platform specific
changes can also be done to the code base
 The propagation between some environments should
also be thought through.
 Ideally a build that reached QA and once certified by
the QA team as release candidate, should
automatically be promoted to client and production
environments
 Should a rebuild be done on the same tag or should
the same code be propagated is a project specific
question?
 As a CM understand the needs of each environment
and the frequency of builds to estimate your own
schedule
scmGalaxy
Automated build
www.scmGalaxy.com

 A build script itself is a good start point for

automation
 It automates the sequence of steps to be executed
per build
 However, with increasing need for integration and
maintaining multiple environments, one needs to
worry about the availability of bandwidth to perform
such tasks
 Automating builds helps answer the following
questions
 How often should the build be started?
 What event should trigger it off?
 On build breaks how should the feedback be routed to the team /
individuals?
 How can an auto deploy be configured and managed?

scmGalaxy
Automated build
www.scmGalaxy.com

 Automated build can be configured to leverage

existing build scripts
 Tools such as cruise control, bamboo etc. provide us
the ability to define an automated build and monitor
them using web consoles
 The data reported from such tools can be used to
provide effective feedback on build breaks and code
quality
 Automating builds is the next step after defining the
build script
 Multiple builds can be defined to ensure a full build
and a full application build are automated and kicked
off based on different events
 Automated build helps in reducing the manual work
of starting off a build

scmGalaxy
Note on continuous integration
www.scmGalaxy.com

 Continuous integration is a term used to describe the

process of triggering a build for each incremental
code modification
 The integration is a continuous process and not a big
bang approach
 It advices the following rules
 single repository
 Event triggered build
 Commit code continuously (every day at least)
 Use a production like machine and deploy the integrated build
 Execute a fast build (take only modified code)
 Use these builds to tag and monitor the best version of the day
 Send feedback of breakages, test coverage reports , code
reviews etc

scmGalaxy
Benefits of continuous
integration
www.scmGalaxy.com

 The cost of fixing a bug early in the project is less

than doing the same at a later stage in the project
 The key is to identify bugs early.
 CI helps in doing this on an incremental basis
 Ability to use automated builds and monitor the
progress of build breaks, code coverage on
continuous basis helps in making some decisions
easier
 Project delivery risk is reduced

scmGalaxy
Tool integration with build
www.scmGalaxy.com

 A typical software project faces the following issues

 Lack of adherence to coding standards
 Lack of good programming practices, especially with novice
programmers
 Lack of white box testing in many cases
 Using simple command line tools one can integrate a
build script with 3rd party tools to obtain simple
reports about the code quality
 If the build script is written using ant, then most
tools provide a simple way to integrate with the ant
tasks
 It is first important to understand the 3rd party tool
and the type of report it generates.
 Most importantly, how often the tool should be run
and the intent of the report

scmGalaxy
Tools integration with build
www.scmGalaxy.com

 PMD – automated code review, standards adherence,

dead code, duplicate code etc.
 JUnit – Unit testing and regression test cases
 EMMA – unit test code coverage
 Code guards – adding conditional execution of log
statements
 AndroMDA – model driven code generator
 ..
 http://www.javapowertools.com/cooltools

 In summary, each of these tools can be iteratively

added to the build script in order to obtain a few
reports about the code.
 The feedback on the quality of the code should be
given to the team for continuous improvement
scmGalaxy
Reports and data analysis -
demo
www.scmGalaxy.com

 PMD – code review

 JUnit and EMMA – code coverage

scmGalaxy
 www.scmGalaxy.com

sG Author: Rajesh Kumar

[email protected]