Download to read offline
Uploaded byTricode (part of Dept)
Continuous Delivery for Open Source Java projects
The document outlines continuous delivery practices for open source Java projects, emphasizing continuous integration, delivery, and deployment as essential components for improving software development efficiency and responsiveness. It highlights the importance of automation, testing, and collaborative processes among development and operations teams, as well as provides insights into major companies like Google, Amazon, and Facebook that successfully implement these practices. Additionally, it lists various tools and prerequisites necessary for effective continuous integration and deployment pipelines.
More Related Content
Similar to Continuous Delivery for Open Source Java projects
Continuous Delivery for Open Source Java projects
- 1. CONTINUOUS DELIVERY FOR OPENSOURCE JAVA PROJECTSBy Igor Stojanovski
- 2. CONTINUUM RELATED TERMS ContinuousIntegration Continuous Delivery Continuous Deployment Deployment Delivery Integration
- 3.
- 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 thecode 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 • Youneed 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 • Commitdaily 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.
- 9. CONTINUOUS DELIVERY 1st principleof 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 doyou 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 isa 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 • Everydeployment 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.
- 14. CONTINUOUS DEPLOYMENT What? Deployment asthe 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 BIGGUYS 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.
- 17. TOOLS OF THETRADE • Code repository • Continuous Integration Server • Code review • Artifact Repository • Environment provisioning tools • Different environments
- 18. CODE REPOSITORY ANDCODE 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 DEPLOYYOUR 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.
Editor's Notes
- #7 You need to have everything needed to build an application version inside the repository = Code, Application configuration, environment and system configuration. Tests, test scripts, etc.
- #8 You need to have everything needed to build an application version inside the repository = Code, Application configuration, environment and system configuration. Tests, test scripts, etc.
- #10 Build quality IN. Don’t make it a last phase of the whole process. Feedback = know what features are needed and which are not Safely = minimizing the possibility of bugs Sustainable way = no overtime, no weekends Make Releases boring Increase quality and stability Reduce cost Customer satisfaction by early and continuous delivery of valuable software
- #11 Configuration – Every environment should be provisioned and configured for automated and easy environment deployment. Automate everything that can be automated, let people focus on the real job. There has to be division of labor between people and machines. That is the lean way of thinking. What is the cheapest way to handle a bug? Don’t check it in into version control! W Edwards Demming: Cease dependence on mass inspection to achieve quality. Improve the process and build quality into the product in the first place.
- #12 We cannot prove absence of defects We can prove absence of known defect Every deployment pipeline is different
- #13 We cannot prove absence of defects We can prove absence of known defect Every deployment pipeline is different For the trade off: we prefer fast feedback instead of getting comprehensive feedback after a very long time. We do not have resources to build and test everything In parallel and fast enough to get both comprehensive and fast feedback Manual stages are in many ways like the acceptance stage. (UAT, Staging, Integration, Production) Deploys self-service through push-button process Build your packages once Deploy the same way to each environment (keep environment similar)
- #15 Configuration – Every environment should be provisioned and configured for automated and easy environment deployment. Automate everything that can be automated, let people focus on the real job. There has to be division of labor between people and machines. That is the lean way of thinking. What is the cheapest way to handle a bug? Don’t check it in into version control! W Edwards Demming: Cease dependence on mass inspection to achieve quality. Improve the process and build quality into the product in the first place.
- #16 - Chuck Rossi – Release Engineer at Facebook: https://www.youtube.com/watch?v=Nffzkkdq7GM
- #21 Atlassiam stack + Jet Brains Team City