Published on

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide


  1. 1. AMSTERDAM / CHICAGO / FRANKFURT / HONG KONG / LONDON / MUMBAI / NEW YORK / SINGAPORE / SYDNEYThe heart of a perfectionist.The soul of an innovator.The blueprint of a solutions provider.RTS Realtime SystemsContinuous Delivery Pipeline PERFORMANCE  STABILITY  CONNECTIVITY  TIME TO MARKET
  2. 2. Continuous Delivery How would you describe or explain continuous delivery
  3. 3. Continuous Delivery What we should focus on while developing, testing and deploying our software and managing our production, test and development environment.
  4. 4. Continuous DeliveryDo we want to deliver constantly? • No, we do not want to deliver constantly, but we want to be able to do so if would like to • Continuous delivery allows you to keep the system production-ready at all times • The system can be released on demand at the push of a button • To release something is a business decision and will be performed manually 4
  5. 5. Continuous DeliveryDelivery pipeline • The pipeline consists of commit stage, acceptance test stage and manual stage • At the end of the pipeline, a binary (it might be an EXE file, RPM, JAR files, etc. but we will call it just “binary”) can be released at the push of a big red button Commit Acceptance Manual Release stage test stage stage button 5
  6. 6. Continuous DeliveryCommit stage • Push current version from SCM (source code management tool) • Build on local developing machine • Run commit tests such as unit tests locally first • If everything is “green”: check in to SCM • Continuous integration: checkout current version, build it and run unit tests • If the build output (we will call it binary from now on) has been assembled and tested successfully continue, otherwise inform (e.g. as email) that this step failed and stop everything and fix the build issue! • If everything is “green”: add binary, test reports and meta data to artifact repository • One check in per day minimum • Build should take under 5 minutes including unit tests 6
  7. 7. Continuous DeliveryCommit stage 7
  8. 8. Continuous DeliveryAcceptance test stage – part one • Get binary from artifact repository => no new re-build! • Deploy and configure it on test environments (Puppet should be used to do this) • Run automated acceptance tests (No human touch on GUI test) • Acceptance tests (to ensure that acceptance criteria/functional requirements are met; will become a regression test in the next revision) • Regression tests (to uncover regressions in existing functionality) • Integration tests (combine modules and test their co-existence e.g. Eurex interface and RTD API) • Capacity tests (meet non functional requirements and do load tests, scalability tests and throughput tests) • Automated smoke tests (it might be a check that a server is reachable via ping) • Any other tests that fit to this stage and can be automated 8
  9. 9. Continuous DeliveryAcceptance test stage – part two • At this stage, also the Puppet installation has been tested! (Same scripts as in prod) • If everything is “green”: add test report and meta data to artifact repository • Otherwise stop the pipeline! • Ideally this stage should take 15 – 20 minutes • The goal is, that this stage is run after the commit stage has successfully been finished 9
  10. 10. Continuous DeliveryAcceptance test stage 10
  11. 11. Continuous Delivery 11
  12. 12. Continuous Delivery 12
  13. 13. Continuous DeliveryManual stage • Get binary output from artifact repository => no new re-build! • Deploy and configure it on test/staging environments (puppet should be used to do this) for manual testing and reviewing (e.g. on stage server) • Perform manual testing: • Smoke tests (basic tests to ensure that the system is up and running) • Exploratory testing (e.g. to test areas that should not have been touched) • Usability testing (check that the functionality is human-friendly) • User acceptance testing (verifies the business requirements) • Showcases (e.g. Sprint Review or feedback sessions during a sprint) • Involved are: QAs, Product Owners, internal customers, external customer • If everything is “green”: add test report and meta data to artifact repository • Otherwise stop the pipeline! • At the end a release button gets provided and business people can decide whether it should be released into production 13
  14. 14. Continuous DeliveryManual stage 14
  15. 15. Continuous DeliveryRequirements • Commit to mainline at least once a day (or: every 30 minutes ) • Every (release) branch needs its own pipeline • Pipeline should be monitored (traffic light) • Test scripts for the monitoring process are needed…  • Metrics: “Senior management should be able to directly see the current status of projects/products.” But not all metrics are really helpful, therefore, check and decide what metrics should be available. • Have a proper release plan • DevOps and its consequences 15
  16. 16. Continuous DeliveryRelease plan • Describe the deployment procedure • Identify what applications have to be smoke tested and identify dependent services/products/components • Remediation plan => might be a roll back plan for instance (how can we roll back?), or a plan to disable a feature (if this is the reason for “rolling back”) with the next release • Schedule and plan testing of roll back and deployment mechanism • Inform Marketing and Solutions at least one week before stuff gets released • Collaboration with test strategy and test plan 16
  17. 17. Continuous DeliveryDevOps • It’s not about roles but rather a culture • Within a team all roles should be shared (“This is not my problem, should the IT-Ops guy try to get it running in production” – this is not what we want to hear in such a case) • Include IT-Ops in planning, reviews (showcases) and project retrospectives • Puppet should also be used within “Development” (since IT-Ops will work closely with Development, we should use the same tools) • IT-Ops scripts should be tested as well (in acceptance test stage) • Installation and configuration done by puppet will automatically be tested when automated tests in acceptance test stage are performed (if the application has not been installed properly, the tests will fail) 17
  18. 18. Continuous DeliveryOrganizational change • Iterative, incremental: continuous improvements • Plan what to do and set goals => plan, do, check, act • Collaboration among departments • Cross-functional teams • Developers are in charge of writing production code and automated tests • QA should pairing with developers to implement automated tests • “We” as team are responsible to fix a red light 18
  19. 19. Continuous DeliveryActions • Introduction of release plans template to be used for all development projects • Engage collaboration between Development and IT-Operations and define the delivery pipeline to be implemented at RTS • Define the automated test responsibility for developers guided by QAs • As we are currently planning and implementing a new release tool, add pipeline functionality to it and provision artifact repository • To be completed by September 28th 19
  20. 20. AMSTERDAM / CHICAGO / FRANKFURT / HONG KONG / LONDON / MUMBAI / NEW YORK / SINGAPORE / SYDNEYThe heart of a perfectionist.The soul of an innovator.The blueprint of a solutions provider.Thank you! Contact PERFORMANCE  STABILITY  CONNECTIVITY  TIME TO MARKET