This document discusses continuous integration and the Jenkins continuous integration server. It defines continuous integration as integrating code changes frequently, usually daily, and verifying them through automated builds and tests to detect errors quickly. The benefits of CI include efficiency, reproducibility, and keeping the mainline code always ready for release. It also discusses best practices like source control, testing everything, and visibility. Jenkins is introduced as a popular open source CI server written in Java that is easy to use, extensible with over 1100 plugins, and enables continuous delivery through flexibility.

1. Continuous Integration
(& Mr Jenkins)
By
Ciro Donato Caiazzo
Geek Talents Dojo – University of Bologna
Bologna, December 2, 2015

2. About me
{
"Name" : "Ciro Donato",
"Surname": "Caiazzo",
"I am": "Software Engineer",
"Working in": "SCAI Consulting",
"With title": "Senior Web Architect",
"ContactMethods" : [
{"Type": "Twitter", "Value": "@CyrusD87"},
{"Type": "Linkedin", "Value": "Ciro Donato Caiazzo"},
{"Type": "E-mail", "Value": "cd.caiazzo@gmail.com"}
],
"Some passions": ["Tecnology","Innovation","Agile","Big data", "Startup"]
}

3. eXtreme Programming

4. eXtreme Programming

5. What is Continuous
Integration

6. Development before CI
commit
Source code control system
Few commits & difficult integration
commit
commit
pull

7. Development before CI
Release manually
Few releases
Test happens late

8. Risk of too many bugs!

9. Continuous Integration
“Continuous Integration is a software development
practice where members of a team integrate their work
frequently, usually each person integrates at least daily -
leading to multiple integrations per day. Each integration
is verified by an automated build (including test) to detect
integration errors as quickly as possible.”
Martin Fowler

10. Development after CI
commit
commit
Source code control system
Continuous integration service
Fail Success

11. Basic process
At every commit
If just one test fails the build is marked as red
If everything OK a release is potentially shippable at
each commit

12. Best practices
• Single source repository
• Keep everything in source control
• Build scripts are source
• Database scripts are source
• Test everything
• Code
• Database scripts
• ...
• Everyone can see what’s happening

13. Rules
• Developers must not access the CI machine
• The CI server should be a clone of production
environment
• The release package must be the output of CI
process

14. Motivations

15. Motivations
• Efficiency
• It can automate everything
• test execution
• setup kit creation
• etc
• Reproducibility
• Automate reduces human errors
• Artifacts versioning
• Traceability

16. Motivations
• Release
The mainline is always ready for release
• Multiple configurations & environments
Agents with different OS, Browsers, Network,
Database, etc

18. Anti patterns

19. Anti patterns
• Fragility
• Occasional failures => Build unstable
• “Don' t stop that build” syndrome

20. Anti patterns
• Poor feedback
• The build spends lots of time to run
• Reproducibility
• the build script should be executable on the dev
machine too

21. Build
• Build = Code
• It evolves along with the project
• It is stored in the source control system with the
rest of the code

22. Where to start

23. About Jenkins
• Continuous integration server
• Written in Java
• Cross- platform
• Open source project
• MIT License

24. Why Jenkins ?
• Easy!
• 1100+ plugin to customize the product
• Extensible
(you can write your own plugin)
• Flexible
• Enable Continuous Delivery
• Open source & Community

25. More…
• http://www.martinfowler.com
• https://www.thoughtworks.com/continuous-
integration
• https://wiki.jenkins-ci.org/

26. Continuous Integration (& Mr. Jenkins)
By
Ciro Donato Caiazzo
Geek Talents Dojo – University of Bologna
Bologna, December 2, 2015