documentcd
TRANSCRIPT
AMSTERDAM / CHICAGO / FRANKFURT / HONG KONG / LONDON / MUMBAI / NEW YORK / SINGAPORE / SYDNEY
PERFORMANCE STABILITY CONNECTIVITY TIME TO MARKET
The heart of a perfectionist.The soul of an innovator.The blueprint of a solutions provider.
RTS Realtime SystemsContinuous Delivery Pipeline
Continuous Delivery
How would you describe or explain
continuous delivery
OR
Continuous Delivery
What we should focus on
while developing, testing and deploying
our software and managing
our production, test and development
environment.
4
Continuous Delivery
Do 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
5
Continuous Delivery
Delivery 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 stage
Acceptance test stage
Manual stage
Release button
OKOK OK
6
Continuous Delivery
Commit 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
7
Continuous Delivery
Commit stage
8
Continuous Delivery
Acceptance 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
9
Continuous Delivery
Acceptance 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
10
Continuous Delivery
Acceptance test stage
11
Continuous Delivery
12
Continuous Delivery
13
Continuous Delivery
Manual 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
14
Continuous Delivery
Manual stage
15
Continuous Delivery
Requirements
• 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
16
Continuous Delivery
Release 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
17
Continuous Delivery
DevOps
• 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)
18
Continuous Delivery
Organizational 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
19
Continuous Delivery
Actions
• 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
AMSTERDAM / CHICAGO / FRANKFURT / HONG KONG / LONDON / MUMBAI / NEW YORK / SINGAPORE / SYDNEY
PERFORMANCE STABILITY CONNECTIVITY TIME TO MARKET
The heart of a perfectionist.The soul of an innovator.The blueprint of a solutions provider.
Thank you!www.rtsgroup.net
Contact us: