This document discusses the evolution of software builds from single source file programs compiled with a command line, to more complex builds of programs with multiple source files and dependencies managed by build automation tools. It describes how builds are used to integrate and test code in a neutral environment separate from development. The key aspects of build infrastructure, management, and continuous integration are outlined.

2. 2

3. A program was made out of a single
source file
 Command Line was used to create a
deployable object from a single source
file

$ gcc –c main.c –o a.out
3

4. 4

5. A program was made out of multiple
source files
 Command Line was not an option to
create a deployable object
 Make scripting language executed a
serious of compile/link steps in a specific
order (outcome - incremental build)

5

6. 6

7. 
Build Process grew more complex
› Components/Layers/Multiple Products
› Pre/Post steps

“build automation” (BA) – build
infrastructure & management (make,
ant, MSBuild, Maven, Jenkins, Bamboo,
TeamCity, RTC…)
is a Practice which became
popular in the late 90s after Microsoft
published its development practices
7

8. A software build which reflects the current
state of the checked in (baselined) code
 In a neutral environment – integration (not
the development environment)
 The build created for the software QA
department for testing purposes

8

9. A
is a neutral build
which takes place automatically
9

10. Source Control
 Compilation/Link
 Packaging
 Tests
 Delivery/Deployment
 Documentation/Release Notes

10

11. Dev
 Integration
 Testing
 Staging
 Production

11

12. Clean environment
12

13. Build Infrastructure – makefiles/ant files/Visual
Studio solution and project files….
› Source Code Directory Structure
› Compiler/Linker options
› Environment Variables
13

14. Build Management
› Build Artifacts
› Which Defects/Features are included in the Build
Result?
› Log file(s)
› Build Results
14

15. Build Servers farm – same OS
and tools setup for consistency
15

16. Integrating with Version Control
System
16

17. Build Dependencies/Order
17

18. Version Numbering
18

19. Reliability – source code do not change
during the build
 Minimizes integration risk
 Improves quality
 Time saver

<# developers> x < build time> x <# working days>
19

20. 




Nightly Build (NB) is periodic, run
overnight when more time (6-8 hours)
Resource-Intensive
Performed by virtual user (builder)
Decoupling the build process from
specific IDEs
Successful Build Results are used for next
day development
20

21. Object Oriented Design
 Multiple Build Options(Debug/Release,
32bit/64bit….)
 Software Components
 No checkout during build

21

22. 22