程序代写代做代考 Java ant lecture_09
lecture_09
Continuous integration
Slides from Tim Storer
Java Build tools
¤ Ant and Ivy
¤ Maven
¤ Gradle (Lab)
Continuous Integration
¤ Integration Hell
¤ Change Management
¤ Monitoring and Maintaining Software Quality
¤ Continuous Deployment
¤ Continuous Integration Environments
Integration Hell
Practices in CI [Fowler, 2006] Practices in CI [Fowler, 2006]
Change management:
Maintain a single source repository
Everyone commits to the mainline every day
Every commit should build the mainline [the trunk] on an
integration machine
Everyone can see what’s happening
Quality assurance:
Automate the build
Make your build self-testing
Test in a clone of the production environment
Keep the build fast
Deployment:
Make it easy for anyone to get the latest executable
Automate deployment
Integration Hell 331
Integration frequency Integration frequency
time
branch
trunk
one large
divergence
(a) large, infrequent commits
Figure: divergence between trunk and feature branches over time
Change Management 332
Integration frequency
Integration frequency
branches
trunk
small divergences
(b) small, frequent commits
Figure: divergence between trunk and feature branches over time
Change Management 332
Feature branching in continuous
integration
Feature branching in continuous integration
Implement the new feature on the
trunk, with frequent commits of small
changes.
Implement the new feature in a branch
and merge changes from the trunk
frequently.
Implement a feature as a prototype
branch and then re-implement the
feature on the trunk in small changes.
Implement the feature as a permanent
branch.
Change Management 333
Detecting broken builds
Detecting broken builds
every time a change is made to the system:
The system should be compiled from source in a clone of the
production environment.
A suite of automated regression tests should be executed on
the complete system.
Appropriate static analysis checks (such as code style
conformity) should be performed and compared to
benchmarks.
Monitoring and Maintaining Software Quality 335
Preventing broken public builds Preventing broken public builds
check�out
working
copy
make
change
private
bui�d
mergepub�ic
bui�d
pass
fai�
pass
fai�
Figure: the continuous integration workflow for a developer
Monitoring and Maintaining Software Quality 337
Preventing broken builds with
branches Preventing broken builds with branches
check�out
working
copy
make
change
private
bui�d
merge
to
branch
bui�d
branch
merge
to
trunk
bui�d
trunk
pass
fai�
pass
fai�
pass
fai�
Figure: preventing broken builds with branches
Monitoring and Maintaining Software Quality 338
Maintaining visibility
Maintaining visibility
Push notifications such as SMS or email.
Broadcast mechanisms such as displaying a status monitor on
a large screen display in the development area.
Monitoring and Maintaining Software Quality 339
CI metrics for project stability
CI metrics for project stability
Unsuccessful builds over last period, which measures how
frequently a project is broken due to integration conflicts.
Average unsuccessful tests per build can be used to estimate
the rate at which defects are introduced into a project by the
implementation of new features
Time to build is important to monitor to ensure that a CI process
remains viable.
Monitoring and Maintaining Software Quality 340
Jenkins build stability reports
Jenkins build stability reports
Figure: build stability reports in Jenkins for these lecture notes
Monitoring and Maintaining Software Quality 341
The importance of fast builds The importance of fast builds
Delays in completing a
build will also delay the
discovery of any problems.
Developers will be
deterred from making
frequent commits,
because the need to wait
for a build to complete
will reduce productivity.
Monitoring and Maintaining Software Quality 342
Tuning build speeds
Tuning build speeds
Reconfigure the build process to
ensure that no unnecessary steps are
being undertaken when a component
is being built.
Configure several di↵erent types of
build that are performed for di↵erent
parts of the project and/or causes of
change.
Prioritise test cases and then partition
them into di↵erent categories for
di↵erent types of build.
Partition large projects into smaller
well defined components that can be
developed concurrently.
Monitoring and Maintaining Software Quality 343
Continuous deployment
Continuous deployment
Ensures that the deployment process is regularly used.
Di↵erent feature variants can be deployed to di↵erent users.
Continuous Deployment 344
Continuous integration environments
Continuous integration environments
Hudson/Jenkins
TeamCity
CruiseControl
BuildBot
Integrity
Table: some continuous integration environments
Continuous Integration Environments 345
Continuous integration environment
workflow Continuous integration environment workflow
Checkout
source Bui�d
Pub�ish
bui�d
report
Execute�unit
and�integration
tests
Pub�ish
�atest
executab�e
Pub�ish
test�report
[on�schedu�ed�bui�d]
Figure: work flow in a continuous integration environment
Continuous Integration Environments 346
Key message
Key point
Continuous integration practices minimise the
disruption caused by rapid, concurrent changes to
software systems.
Summary 347
PI Question (session1280)
In AE2, How many bugs have you found?
¤ A: 1
¤ B: 2
¤ C: 3
¤ D: 4
