1. AMSTERDAM / CHICAGO / FRANKFURT / HONG KONG / LONDON / MUMBAI / NEW YORK / SINGAPORE / SYDNEY
The heart of a perfectionist.
The soul of an innovator.
The blueprint of a solutions provider.
RTS Realtime Systems
Continuous Delivery Pipeline
PERFORMANCE  STABILITY  CONNECTIVITY  TIME TO MARKET

2. Continuous Delivery
How would you describe or explain
continuous delivery

3. 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
4

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 Acceptance Manual Release
stage test stage stage button
5

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
6

7. Continuous Delivery
Commit stage
7

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
8

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
9

10. Continuous Delivery
Acceptance test stage
10

11. Continuous Delivery
11

12. Continuous Delivery
12

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
13

14. Continuous Delivery
Manual stage
14

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
15

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
16

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)
17

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
18

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
19

20. AMSTERDAM / CHICAGO / FRANKFURT / HONG KONG / LONDON / MUMBAI / NEW YORK / SINGAPORE / SYDNEY
The heart of a perfectionist.
The soul of an innovator.
The blueprint of a solutions provider.
Thank you! Contact us:
www.rtsgroup.net p.eid@rtsgroup.net
PERFORMANCE  STABILITY  CONNECTIVITY  TIME TO MARKET