22
CONTINUOUS DELIVERY FOR OPEN SOURCE JAVA PROJECTS By Igor Stojanovski

Continuous Delivery for Open Source Java projects

  • Upload
    tricode

  • View
    649

  • Download
    1

Embed Size (px)

Citation preview

Page 1: Continuous Delivery for Open Source Java projects

CONTINUOUS DELIVERY FOR OPEN SOURCE JAVA

PROJECTSBy Igor Stojanovski

Page 2: Continuous Delivery for Open Source Java projects

CONTINUUM RELATED TERMS

Continuous Integration

Continuous Delivery

Continuous Deployment

Deployment

Delivery

Integration

Page 3: Continuous Delivery for Open Source Java projects

CONTINUOUS INTEGRATION

Page 4: Continuous Delivery for Open Source Java projects

CONTINUOUS INTEGRATIONThe 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

Page 5: Continuous Delivery for Open Source Java projects

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

Page 6: Continuous Delivery for Open Source Java projects

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

Page 7: Continuous Delivery for Open Source Java projects

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

Page 8: Continuous Delivery for Open Source Java projects

CONTINUOUS DELIVERY

Page 9: Continuous Delivery for Open Source Java projects

CONTINUOUS DELIVERY1st 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.• Make the developers happy.

Page 10: Continuous Delivery for Open Source Java projects

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

Page 11: Continuous Delivery for Open Source Java projects

DEPLOYMENT PIPELINEIt 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

Page 12: Continuous Delivery for Open Source Java projects

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

• Manual stages (self serviced, Pull instead of Push)

Page 13: Continuous Delivery for Open Source Java projects

CONTINUOUS DEPLOYMENT

Page 14: Continuous Delivery for Open Source Java projects

CONTINUOUS DEPLOYMENTWhat?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!

Page 15: Continuous Delivery for Open Source Java projects

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.

Page 16: Continuous Delivery for Open Source Java projects

CONTINUOUS DELIVERY TOOLS

Page 17: Continuous Delivery for Open Source Java projects

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

Page 18: Continuous Delivery for Open Source Java projects

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

Page 19: Continuous Delivery for Open Source Java projects

CODE QUALITY• SonarQube

• Industry standard• Free• No hosted option

• Coverity• Free for open Github

repos• Codacy

• Free for open Github repos

Page 20: Continuous Delivery for Open Source Java projects

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

Page 21: Continuous Delivery for Open Source Java projects

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)

Page 22: Continuous Delivery for Open Source Java projects

EXAMPLE STACK

+ + +