4. An important part of any software development
process is getting reliable builds of the software.
- Martin Fowler, Chief Scientist, ThoughtWorks
5. What is Continuous Integration?
A Fully Automated, Reproducible Build Process
Runs many times a day – as often as needed
Available to run on-demand in a single command
Built from scratch from source control (ARCS)
Includes Unit Testing and Code Coverage
Automated Source Code Review and Quality Analysis
Deliverables include latest distribution e.g. jar, ear
Successful compilation AND testing I.e. not a build
“attempt”, but a build that works!
6. The Benefits
Reduced Time to Market
– Cuts testing time due to earlier detection of potential issues
– Significantly reduces manual source code review efforts
Improved Product Quality
– Reduces bugs by uncovering integration issues early on
– Continuous testing enforces code quality
– Source code analysis enforces best programming practices
– Improved Reliability, Maintainability, Testability, Reusability
Increased Developer Productivity
– Automated source analysis reduces manual review efforts
– Developers can focus on what needs to be fixed
– Developers can gain unique perspective on best
programming practices and industry-standard patterns
8. Build Process: Setup
Checks Build Mode and JDK
– Supported Build Modes are iAS and DB
– Supported JDK: 1.1.8 (may drop), 1.3 and 1.4
– Classpath uses iAS 1.0.2.2 or 9.0.4 home based on JDK
Cleans build area and creates directory structure
Copies any dependent FND libraries e.g. fndctx.jar
Checks out latest source code from RCS
Ignores file patterns specified in build.excludes
Can check out for a given release label if needed
Performs iAS or DB specific tasks
– E.g. Copy the appropriate Workflow Context factories
9. Build Process: Compile
Instruments source code for code coverage
– Original source code backed up to ./prof-bak
– Generates BasicBlocks file containing source information
Compiles all source code
– For Workflow, following modules are compiled:
Workflow Engine
Workflow Configuration Assistant
XML Gateway Engine
XML Gateway Message Designer
Build all the jar, war and ear files
– Delivers a single workflow.jar along with other files
10. Build Process: Test
Checks out test source code into build area
– Unit tests copied from $psa/java/ut
– Test data and RTs copied from $psa/test
Compiles the test source code
Sets the environment needed for testing
– Sets the required environment variables
– Puts data directory in the classpath for loading test data
– Puts junit.jar in the classpath
Runs all (or specified) Unit Tests
Run any additional RTs (manually if needed)
Produces the profile files for code coverage
11. Build Process: Code Coverage
Reads all generated profile files
– Initial profile files automatically generated from Unit Tests
– More profile files can be generated by running RTs
Generates code coverage by module
– Compares profile against BasicBlocks generated file
– Groups by modules defined in the ProfileGroups file
– Ignores all blocks mentioned in Infeasible file
Generates marked up source html files
– Indicating non-covered and heavy-hit blocks
Restores all original source code from backup
– Unless of course you need to re-run after RTs
12. Build Process: Source Analysis
JavaNCSS
– Analyzes Complexity of Source Code
Max Non-Commented Source Statements
Max Cyclomatic Complexity (loops, conditions)
Max Classes per Package and Methods Per
Class
Min Javadoc Per Method
– Helps Refactor code to reduce complexity
Improve Maintainability
Reduce bugs
13. Build Process: Source Analysis
JDepend
– Provides Dependency and Stability Inference
– Analyzes Cyclical References between classes
– Helps in Refactoring code for Maintainability
GSCC
– Runs GSCC checks per ARU guidelines
– Some GSCC checks not applicable in Standalone mode
Memory Leak Checker (ATG Utility)
– Identifies potential memory leaks by smart parsing
– Very basic, may not be applicable for J2EE code
15. Build Process: Source Analysis
CheckStyle
– Checks conformance to industry best-practices
– Significantly reduces developer time and effort for manual,
tedious code review
– Helps learn industry standard best programming practices
– Helps in Reusability and Maintainability
– Most non-compliances can be fixed by Jalopy
DocCheck
– Checks for non-compliance of Javadoc standards
– Checks missing comments at various levels, saving time
– Suggests the comments for self-evident methods
– Provides suggestions that can be cut-n-pasted
– Helps in Maintainability
16. Build Process: Publish Reports
Generates Javadoc with a PUBLIC scope
Publishes to public web server
– Build Log Files and Test Outputs of FNDLOG
– JUnit Results
– Code Coverage Analysis
– Javadoc and DocCheck Reports
– GSCC and MemLeakChecker Output
– JavaNCSS and JDepend Reports
– Checkstyle Analysis
Notifies Recipients by Email of Successful Build
Master build page updated with build information
17. Build Progress
Metric WF2.6* WF3.0**
Lines of Code (w/o comments) 53,046 8,294
Methods 4,832 1,093
Classes 525 96
Javadoc 1,786 756
Unit Tests 132 130
Unit Test Success Rate 96.97% 96.92%
Code Coverage (Unit Tests) 19.17% 48.38%
* Applies to Standalone Java Build WF26.185 as of 08.07.2003
** Applies to Standalone Java Build WF30.12 as of 07.25.2003
Next Steps: OAM and Diagnostics soon to be enabled for continuous builds.
18. Build Targets
Clean Build
– Source modifications checked every hour on weekdays
– 5 minute “quiet period” before starting build
– Removes all derived / generated objects
– Checks out and compiles all source code
– Creates distribution executables
Full Build (Every 4 Clean Builds)
– Performs Clean Build as above
– Compiles and Runs All Unit Tests
Master Build (Every 8 Clean Builds)
– Performs Full Build as above
– Runs Code Coverage and Source Code Analysis
– Publishes Reports and Javadoc to Web Server
– Purges log files older than 7 days
19. Build Modes
Continuous Build (Official Build Label)
– No manual intervention required
– Executed From: /wfdev/wf/tools/buildtool/wf26
– Outputs to /wfdev/wf/buildstage/wf26
On-Demand Build (Build Label “X”)
– Copy build files to any local directory (one time) and run
– Run buildnow buildmaster.xml <targets>
– Outputs to /tmp/wf/buildstage/wf26
Configuration Files
– buildmaster.*, config.xml – DO NOT MODIFY
– build.xml, build.properties – Modify as needed
– Better still, pass in properties as –D parameters at runtime