Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Turnkey Continuous Delivery

44 views

Published on

When it comes to Continuous Integration and Delivery, the common idea is that the tools necessary to practice it are complex and require a lot of study and time to create the basic infrastructure.
With this workshop we want to show a "turnkey" solution to experiment the Continuous Delivery technique in just a few minutes! And show that the challenge is not to dominate the tools, but to change ourselves and the way we work and approach this topic.

Published in: Software
  • This whitepaper explains how we built a continuous testing framework for one of our high value enterprise clients and the challenges we faced along with the solutions we created to overcome those challenges. http://bit.ly/2FTSWT2
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Be the first to like this

Turnkey Continuous Delivery

  1. 1. TURNKEY CONTINUOUS DELIVERY Gianni Bombelli bombelli@intre.it https://github.com/bombix https://www.linkedin.com/in/gianni-bombelli Monza, 3 Dicembre 2018 1
  2. 2. EXTREME PROGRAMMING continuous integration ten minute build integration whole team slack weekly cycle monthly cycle stories planning programming incremental design test-first programming primary energized work programming shared code code &test s ingle code base team continuity shrinking teams real customer involvement root cause analysis incremental deployment dailydeployment pay-per-use negotiated scope contract tea m business coro llary XP Practices Turnkey Continuous Delivery 2
  3. 3. 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. Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly. Turnkey Continuous Delivery 3
  4. 4. CONTINUOUS ... Kofy Senaya Director of Product @ Clearbridge Mobile Continuous Delivery is similar to Continuous Integration. You are building a product that can be released to production at any time. Continuous Delivery requires building testing, and releasing faster and more frequently. Continuous Integration happens before you build as you are testing code. Delivery means you can release something to the staging environment or the pre-production environment. Continuous Delivery is when your code is always ready to be released but isn’t pushed to production unless you make the decision to do so. It is a manual step. With Continuous Deployment, any updated working version of the app is automatically pushed to production. Turnkey Continuous Delivery 4
  5. 5. TOOLS Turnkey Continuous Delivery 5
  6. 6. WHAT DO WE DO NOW? bootstrap our Continuous Delivery and test environment configure the tools necessary to manage and build our software create our build Continuous Delivery pipeline develop a simple micro-service REST server written in ES6 executed with Node.js released as a docker image Turnkey Continuous Delivery 6
  7. 7. REPOSITORIES Build and Release Infrastructure Example Project Remove the remote named origin Checkout the tag start Reset master branch to the commit with the start tag Turnkey Continuous Delivery https://github.com/bombix/workshop-turnkey https://github.com/intresrl/microservice-example-hex2hsl 7
  8. 8. INFRASTRUCTURE Turnkey CD Testing Staging Turnkey Continuous Delivery Production 8
  9. 9. INFRASTRUCTURE AS CODE Turnkey Continuous Delivery 9
  10. 10. WORKFLOW - F.1 Turnkey Continuous Delivery 10 . 1
  11. 11. WORKFLOW - F.2 Turnkey Continuous Delivery 10 . 2
  12. 12. WORKFLOW - F.2 MERGE Turnkey Continuous Delivery 10 . 3
  13. 13. WORKFLOW - F.1 MERGE Turnkey Continuous Delivery 10 . 4
  14. 14. BUILD AUTOMATIONPush P oll Checkout Source Code Static Code Analysis Build Test pre-deploy Build Artifact Push Artifact to Repo Deploy & Run Test post-deploy Cleanup Turnkey Continuous Delivery 11
  15. 15. ESERCIZIO 0 Turnkey Continuous Delivery 12 . 1
  16. 16. ESERCIZIO 0 Turnkey Continuous Delivery 12 . 2
  17. 17. ESERCIZIO 1 Turnkey Continuous Delivery 13 . 1
  18. 18. ESERCIZIO 1 Turnkey Continuous Delivery 13 . 2
  19. 19. ESERCIZIO 2 Turnkey Continuous Delivery 14 . 1
  20. 20. ESERCIZIO 2 Turnkey Continuous Delivery 14 . 2
  21. 21. ESERCIZIO 2 Turnkey Continuous Delivery 14 . 3
  22. 22. ESERCIZIO 3 Turnkey Continuous Delivery 15 . 1
  23. 23. ESERCIZIO 3 Turnkey Continuous Delivery 15 . 2
  24. 24. ESERCIZIO 3 Turnkey Continuous Delivery 15 . 3
  25. 25. ESERCIZIO 4 Turnkey Continuous Delivery 16 . 1
  26. 26. ESERCIZIO 4 Turnkey Continuous Delivery 16 . 2
  27. 27. ESERCIZIO 5 Turnkey Continuous Delivery 17 . 1
  28. 28. ESERCIZIO 5 Turnkey Continuous Delivery 17 . 2
  29. 29. ESERCIZIO 5 Turnkey Continuous Delivery 17 . 3
  30. 30. IT'S ENOUGH ? single shared code-base automated build & merge different branches self-testing build integrate every commit ten-minutes build & fail fast! everyone can see what's happening end-to-end test automated deployment test the deployment test in a production-like environment Turnkey Continuous Delivery 18
  31. 31. NEXT STEPS ... Build Artifact Push to Artifact Repository Deploy on a test or staging server Run it Execute the post-deployment tests Turnkey Continuous Delivery 19
  32. 32. BUILD ARTIFACT AND PUSH Turnkey Continuous Delivery stage('Build Docker Image') { def container-name = ${pipelineName}-${env.BRANCH_NAME} sh "docker -H tcp://192.168.50.91:2375 build -t 192.168.50.91:5000/${container-name}:${env.BUILD_ID} -t 192.168.50.91:5000/${container-name}:latest ." } stage('Push to Docker Registry') { def container-name = ${pipelineName}-${env.BRANCH_NAME} sh "docker -H tcp://192.168.50.91:2375 push 192.168.50.91:5000/${container-name}:${env.BUILD_ID}" sh "docker -H tcp://192.168.50.91:2375 push 192.168.50.91:5000/${container-name}:latest" } 20
  33. 33. DEPLOY & RUN Turnkey Continuous Delivery stage ('Deploy and Run') { if (env.BRANCH_NAME == 'master') { print "Deploy docker container to : staging environmet" sh "ansible-playbook -i /ansible/inventory/hosts.yml /ansible/hex2hsl.yml --limit staging" } else { print "Deploy docker container to : testing environmet" sh "ansible-playbook -i /ansible/inventory/hosts.yml --extra-vars 'hex2hsl_branch=${env.BRANCH_NAME} hex2hsl_port=${test_ /ansible/hex2hsl.yml --limit testing" } } 21
  34. 34. TEST POST-DEPLOY Turnkey Continuous Delivery stage('Test post-deploy') { def test_url = '' if (env.BRANCH_NAME == 'master') { test_url = 'http://192.168.50.93:3100' } else { test_url = 'http://192.168.50.92:' + test_port } sh "npm run test:post-deploy -- --test_url=${test_url}" step([$class: 'XUnitBuilder', thresholds: [[$class: 'FailedThreshold', unstableThreshold: '1']], tools: [[$class: 'JUnitType', pattern: 'test-report/test-post-deploy-report.xml']]]) } } 22
  35. 35. AND NOW, IT'S ENOUGH ? Regression tests: we always test everything e2e tests: yes, post-deploy tests runs on staging Security scans: only dependency audit performed by npm Performance test: nope! Deployment test: yes, deploy on staging environment Turnkey Continuous Delivery 23
  36. 36. 24
  37. 37. Special thanks to Ferdinando Santacroce @jesuswasrasta 25
  38. 38. 26

×