SkopjeTechMeetup 4 - 2nd presentation: Continuous Delivery for Open Source Java projects In order to have a quality open source Java project the only thing you need is the knowledge and the will to do it. Everything else is free and available. This presentation is for such a set of free tools that allow you to have continuous integration, inspection and delivery of your open source projects.

1. CONTINUOUS DELIVERY FOR
OPEN SOURCE JAVA
PROJECTSBy Igor Stojanovski

2. CONTINUUM RELATED TERMS
Continuous Integration
Continuous Delivery
Continuous Deployment
Deployment
Delivery
Integration

3. CONTINUOUS
INTEGRATION

4. CONTINUOUS INTEGRATION
The term 'Continuous Integration' originated with the Extreme
Programming development process, as one of its original twelve
practices.
What?
• A development practice of merging all developer working copies to
a shared mainline several times a day.
Why?
• To avoid “integration hell”
• To get fast, automated feedback on the correctness of the
application every time there is a change to the codebase

5. CONTINUOUS INTEGRATION
SCENARIO
Get the code from the
central code repository
Add new or change
existing features
Get new changes from
the repository and
integrate with your new
changes
Commit the integrated
code back to the
repository
Initiate a build on the
mainline to check its
correctness
Basic prerequisites:
• Central code repository
• High degree of automated test coverage

6. CONTINUOUS INTEGRATION
REQUIREMENTS
• You need a central code repository
• Everything needed to build the application should be in the repository
• Everything that can be built, should not be in the repository
• You need automated tests

7. CONTINUOUS INTEGRATION
POINTERS
• Commit daily in the mainline/trunk and do not misuse branches
• Frequent commits encourage developers to break down their work into
smaller chunks. TDD could help.
• Every commit on the mainline should initiate a mainline build. This is where
a Continuous Integration Server comes in handy.
• The build should be fast. Deployment pipelines could help!
• If the build is broken the response to fix it should be even faster.
• Environments should be as similar as possible to the production
environment

8. CONTINUOUS DELIVERY

9. CONTINUOUS DELIVERY
1st principle of the Agile Manifesto: Customer satisfaction by early and
continuous delivery of valuable software
What?
• The practice in which you build software so it can be released into
production at any given moment
Why?
• So you can get fast, automated feedback on the production readiness of
your application every time there is a change - to code, infrastructure or
configuration.
• So you can get changes (features, configuration, bug fixes, experiments, ...)
into production or into the hands of users safely and quickly in a
sustainable way.
• Reduce cost of software development
• Make the client happy.

10. CONTINUOUS DELIVERY
PREREQUISITES
What do you need in line in order to say you are doing continuous delivery?
• Continuous integration
• Comprehensive configuration management
• Excellent automated testing at multiple levels
• Logging and Monitoring
Culture related:
• Close cooperation between everyone involved in the delivery process. That
is, you need DevOps.
• Joint responsibility
• Build quality IN
• Automate everything possible
• ALWAYS try to get better

11. DEPLOYMENT PIPELINE
It is a representation of the process for getting changes form version control
into production.
Development Team
Checks into
version control
Commit Stage
Trigger
Automated
Acceptance Tests
Approval
Manual Validation
Approval
Release

12. DEPLOYMENT PIPELINE
CHARACTERISTICS
• Every deployment pipeline Is different
• Trading off fast feedback against comprehensive feedback
• To achieve this we should keep the pipeline short but as parallel as
possible
• Because of this in the example there is a Commit stage and an
Acceptance Stage
• Commit stage:
• Unit Tests
• Package
• Code quality analysis
• Possible send artifacts to an artifact repo
• Acceptance stage
• Configure environment
• Deploy artifacts (From some sort of artifact repository)
• Do all kinds of tests
• Tare it down

13. CONTINUOUS
DEPLOYMENT

14. CONTINUOUS DEPLOYMENT
What?
Deployment as the last automated step of the delivery process
Why?
You’ve done everything possible to torture the code in a sustainable and
automatic way and there are no reasons why it shouldn’t really go directly into
production
This really isn't as crazy as it seems!

15. CONTINUOUS DEPLOYMENT: THE
BIG GUYS
Google:
• 15,000 engineers work from
the HEAD revision of a single
Perforce trunk.
• 50% of the code will be
changed in any given month.
• Google has written a
comprehensive book about
how they perform QA while
continuously releasing.
Amazon:
• New code is deployed to
production once every 11.6
seconds during a normal
business day.
• That’s 3,000 production
deployments per day.
• They’ve invested an
enormous amount of time
and money into creating an
architecture that facilitates
small, orthogonal, frequent
code pushes.
Facebook:
• Each of 5,000 engineers
commits to trunk HEAD at
least once a day and the
code at trunk HEAD is
pushed to production twice
daily.
• Facebook has no dedicated
QA team. All responsibility
for testing rests with the
software engineers.
• They’ve invested heavily in
infrastructure that provides
zero-downtime deployment
at Facebook scale.

16. CONTINUOUS DELIVERY
TOOLS

17. TOOLS OF THE TRADE
• Code repository
• Continuous Integration Server
• Code review
• Artifact Repository
• Environment provisioning tools
• Different environments

18. CODE REPOSITORY AND CODE
REVIEW
• Bitbucket
• 5 users: free
• ProjectLocker
• Git, SVN
• Free trial
• CloudForge
• Free trial
• Github
• FREE: – unlimited collaborators,
unlimited public repositories, 0
private repositories
• SourceForge
• Free
• SonarQube
• Industry standard
• Free
• No hosted option
• Coverity
• Free for open Github
repos
• Codacy
• Free for open Github
repos

19. CODE QUALITY
• SonarQube
• Industry standard
• Free
• No hosted option
• Coverity
• Free for open Github
repos
• Codacy
• Free for open Github
repos

20. CONTINUOUS INTEGRATION
SERVERS
• Travis-CI
• Free for open GitHub repos
• Jenkins
• Hosted for free on OpenShift
• Codeship
• Free for open GitHub repos
• Snap
• Free for GitHub Public repos and 1 build at a time
• CircleCI
• Free for 1 concurrent build

21. WHERE TO DEPLOY YOUR
APPLICATION
- Amazon Web Services (Something is free.)
- Microsoft Azure (Something is free.)
- Google Cloud platform (The trial is free.)
- OpenShift
- Heroku
- Lots of cheap hosting services (Not free after all)

22. EXAMPLE STACK
+ + +