This presentation covers the importance and principles of continuous integration (CI) in software development, emphasizing the need for regular, automated building and testing to improve efficiency and reliability. It outlines the CI process, key team responsibilities, and highlights the benefit of using tools like Black Duck for open source software inspection. Additionally, it showcases successful case studies demonstrating significant improvements in build times and testing efficiency after implementing CI practices.

1. Continuous Integration
—An Overview
Dr. Robert Burnett
Director, Software Engineering
This presentation consists of L -3 Communications Corporation general capabilities
and administrative information that does not contain controlled technical data as
defined within the International Traffic in Arms (ITAR) Part 120.10 or Export
Administration Regulations (EAR) Part 734.7-11.

2. The practice of regular, comprehensive, and
automatic building and testing of applications
in software development
Continuous Integration
Compile
Build
Test
2

3. Reliance on manual processes to build
and test software is problematic.
• Error prone.
• Lack of consistency
• Build and integration processes have become
more complex
• Static testing is a critical step in the process
• Quick turnaround on validating changes is now
required to:
• Reduce cost associated with finding defects late
• Reduce time to deploy changes/updates
Why is Continuous Integration (CI) so important?
3

4. Continuous Integration is a development practice
that requires developers to integrate code into a
shared repository several times a day. Each
commit is then verified by an automated build,
allowing teams to detect problems early.
Integration builds are tested early and often
and functional builds are maintained at all times.
• Don’t leave the build broken
• In a Continuous Integration environment
you should never have a integration build
in a ‘failure state’ for long.
A Fundamental change in how you think about software development

5. Martin Fowler’s “original” principles of Continuous Deployment
1. Configuration
control single code
repository
2. Automate the
build process
3. Automate
testing
4. Developers
commit changes
to the baseline
daily
5. Build every
commit (to
baseline)
6. Keep the build
fast
7. Test in a clone
of the production
environment
8. Make it easy to
get executable
code
9. Give everyone
full visibility to the
results of the
latest build
10. Automate
deployment
Continuous Integration
5

6. The CI Build System
Developers
Workspace
CI server
Dashboard
Version Controlled
Repository
Poll
Commit
Changes
Results
Build and Test
Servers
6

7. Continuous Integration - Basic steps
• Developers load the project source code into their
private workspaces. When done, commit the changes
to the repository
• The CI server monitors the repository and processes
changes when they occur. The CI server:
• Builds the system and runs unit and integration tests
• Releases deployable artifacts for testing
• Assigns a build label to the version of the code it just built
• Informs the team of the successful build
• Alerts the team if the build (or individual tests) fail
• The team fixes the issue at the earliest opportunity
• Report nightly build status on Dashboard
7

8. Continuous Integration
– Team responsibilities
Commit frequently
Don’t commit broken code
Don’t commit untested code
Don’t commit when the build is broken
Don’t go home after committing code
until the system builds
8

9. 1. Before committing changes, check to see if a build is currently in the "Successful"
status. If not, you should assist in fixing a build before committing new code.
2. If the status is currently "Successful", you should update your personal workspace
to this configuration.
3. Build and test locally to ensure the update doesn't break functionality.
4. If Successful, commit the changes to the repository.
5. Allow CI to complete with new changes.
6. If build fails, stop and fix on your machine. Return to step 3.
7. If build passes, continue to work on the next item.
Continuous Integration checklist
9

10. 10

11. Adding BlackDuck to our Continuous code inspection
11
Cause for caution
Not all Open-Source Software is Free
Open-Source Software (Free or other wise)
may have security vulnerabilities.
Sandwich from The Linux Foundation, Flight 2017
Free and Open-Source Software
(FOSS)
FOSS is a major part of the software
development landscape which cannot
be ignored.
FOSS provides software developers with a
significant advantage of not having to reinvent
the wheel (or re “implement” the wheel) for
their project.

12. Scans code for use of FOSS
• Identifies OSS components in code
(Generates FOSS BOM)
• Provides associated OSS license, compliance
and risk of usage
• Provides security vulnerability information for current
and previous scans
• Provides alert of the usage of unapproved OSS
How BlackDuck Hub Helps
12

13. Complex software development environments supporting multiple targets.
• Embedded ( C/C++,Python, etc.), Application (Java, JavaScript, etc.)
Significant variation in the software development processes
• Agile , Waterfall, and every thing in between
Significant variation in the developers level of engagement and buy-in with CI.
• First impression is this is “extra work”
Our experience at L3
13

14. 14
The Chris Shayan Continuous Delivery Maturity Matrix
Our Progress in the last 5 years
Continuous Delivery
Maturity Matrix

15. Results of using the Test Automation (TA) on pilot Project A
Test automation in support of Continuous integration
15
Before TA After TA % Improvement
Time to write tests and perform
dry-runs per requirement
4 hrs/req 1.8 hrs/req 55%
Time to test each requirement
in formal test
5 mins/req 0.34 mins/req 93%
Total execution time 12 hours
35 mins auto
+ 1 hrs manual
87%

16. Results:
• Schedule for integration effort was predictable
• Lab Integration of software components was very quick (within a couple of hours)
or worked 100% the first time since all components were already thoroughly tested
in simulation
• Quick evaluation of code change during compilation and unit test
• Quick evaluation of pass/fail on new builds during integration via automated
regression suites
• Zero defects found during SW Verification dry runs and formal testing
• Zero defects found during System Verification dry runs
100% Code Coverage and Continuous Integration on Project E
16

17. Other examples
17
Project A2-L:
After implementing core pieces of CI (Build
automation and Test automation), the cycle
time for a new build release (tested &
verified) was reduced from and manually
intensive 3+ day effort to 4 hours.
Project A3-M:
After implementing core pieces of CI time for
incremental release (built, tested & verified)
was reduced from 146 hours to 38 hours

18. Main reasons for Continuous
Integration to fail
Infrequent check-ins, which lead to delayed integrations
Broken builds, which prevent teams from moving
on to other tasks
Minimal feedback, which prevents action from occurring
Receiving spam feedback, which causes people
to ignore messages
Possessing a slow machine, which delays feedback
Relying on a bloated build, which reduces rapid feedback
18

19. Thank you!