Continuous Delivery (CD) is a software engineering approach that allows teams to produce software in short cycles, ensuring it can be released to production at any time. CD separates the task of delivering software from the development process, enabling rapid feedback, improved quality, and higher customer satisfaction. Implementing CD requires changes in organizational mindset, investment in tools and automation, and adoption of continuous integration practices.

1. Continuous Delivery
Erez Attar - Jan 2016

2. Continuous Delivery
what is it ?
why we need it?
who is it for ?
how we do it?

3. What is it ?

4. SDLC (Software Delivery Life Cycle) Evolution
● Waterfall start making software ready for release
when all of the functionality for the release has been
developed.
● Agile software ready for release throughout
development at periodic intervals.

5. SDLC (Software Delivery Life Cycle) Evolution
● Continuous Delivery subset* of agile in which software ready for release at all
times during development.

6. Continuous Delivery - Wikipedia
Continuous Delivery (CD) is a software engineering
approach in which teams produce software in short cycles,
ensuring that the software can be reliably released at any
time.[1]

8. Continuous D/D/I dependencies
● Continuous Deployment means that every change is automatically deployed
to production
● Continuous Delivery Enables the software to be released to production at any
time.
● Continuous Integration refers to integrating, building, and testing code within
the development environment.

9. Continuous integration
merging all developer working copies to a shared mainline several times a day
● Automate the build
● Build Self Testing
● Everyone commits to baseline every day
● Every commit should be built
● Test in a clone of production
● Everyone can see results of latest build

10. History
● Grady Booch 1991
● XP (Kent Beck 1999)
● Agile Manifesto (Fowler 2001)
● ThoughtWorks Studios
(Cruise CI 2008 & Go CD 2010)
● Continuous Delivery (Jez Humble & David Farley 2010)

11. CD is not ….
Continuous Delivery is not about shorter cycles for making the software ready for
release. CD is about moving away from making the software ready as a separate
activity, and instead developing in a way that means the software is always ready
for release.
Ready for release does not mean actually releasing into production very
frequently. Continuous Delivery doesn’t require frequent releases, it only requires
ensuring software could be released with very little effort at any point during
development

12. Thinking Point
How long it will take to your organization to deliver a
change that include one line of code change ?

13. Who is it for ?

14. Who is it For ?
every development team should be practicing continuous
delivery
To separate from continuous Deployment, It’s the human-decision factor that distinguishes continuous
delivery from continuous deployment,

15. Why do we need it ?

16. Benefits
● Accelerated Time to Market: CD lets an organization deliver the business value
inherent in new software releases to customers more quickly. This capability
helps the company stay a step ahead of the competition
● Software is deployable throughout its life-cycle
● fast, automated feedback on the production readiness of their systems any time
somebody makes a change to them
● push-button deployments of any version of the software to any environment on
demand

17. more Benefits
Improved Productivity and Efficiency: Significant time savings for developers, testers,
operations engineers, etc. through automation.
Building the Right Product: Frequent releases let the application development teams
obtain user feedback more quickly.

18. and few more Benefits
Improved Product Quality: The number of open bugs and production incidents
decreased significantly.
CD is closely tied to quality delivery and requires companies to adopt a new mindset of
delivering regular quality application updates.
Building an application quickly usually means skimping on testing or reducing the
number of planned features to meet a target delivery date
Improved Customer Satisfaction: A higher level of customer satisfaction is achieved.

19. Benefits - Some numbers
● Reduce production errors by up to 98%
● Improve deployment time by as much as 20x
● ROI of 389%
● Payback in 2.8 months over a 3 year period

20. How do we do it

21. DZone’s 2015 Continuous Delivery Survey

22. Are you implementing Continuous Delivery
?
● is your software confirmed to be in a shippable state every time a new
feature or patch is added?
● Does your team perform push-button deployments of any desired version of
your software to any environment on-demand?
● Do all of the stakeholders have immediate visibility into the production
readiness of your systems?

23. Continuous Delivery “on the cheap” ???
NO
“on the cheap” recipe for spending time and money on failure.
● CD requires change from teams across the organization.
● CD requires focused investment in tooling, hardware, and people.

24. Importand Mindset change
You can easily envision that the CD practices also provides a different set of data to
the teams.
1. Does the new feature work correctly on a production like server environment?
2. Do the packages install correctly?
3. Does the automated process that will be used throughout the delivery pipeline
work? (one package, same delivery, many times, to all environments)

25. CD (Continous Delivery) Ingredients
● CI (Continuous Integration)
● Automation
● CM (Configuration Management)

26. The Process

27. Testing road blockDevelopement driven by CRs
Manual testing cannot keep up with the pace
test process is unsystematic
Manual testing is limited in scope
Manual testing frameworks don’t react well to code changes
Testers are forced to not fully testing the software, which leads to
defects
creating the data from scratch—a time-consuming and error-prone
process
Bottom line: legacy test methods can’t keep pace with a continuous
application delivery model

28. CD requires new Test Model
Req Model
simulate unavailable/dependent systemsModel Based testing
To eliminate manual testing
and bottlenecks
eliminate defects much earlier in the SDLC
14x more expensive to fix bugs in production than in development
+

29. Tests Types

30. Test Environment
Continuous delivery is only possible when
● test environments are staged and used in hours, not weeks.
● when test environments can be reconfigured with flexibility.

31. Gather right Test Data and Fast
● Test data on demand that any team can use whenever it is needed.
● Quickly provision high-quality, secure data for better software testing.
Test Data Management Solution

32. Automatic Change and Test Maintenanace
Requirements change
Test cases automatically update

33. END

34. Tools to practice Continuous Delivery

35. CA Test Solutions
● Align business planning to test cases utilizing CA Test Case Optimizer
● Create accurate and virtual test data using CA Test Data Manager
● Simulate backend services through CA Service Virtualization
● Create automatic virtual services through deep transactional analysis with CA
Continuous Application Insight
● Build and reuse test cases quickly and easily with CA Application Test
● Automate the test process end-to-end with CA Release Automation

36. Tools to practice Continuous Integration
commonly used CI tools (Automation of building, testing, deploying):
● Jenkins
● Hudson
● Travis
● Bamboo.

37. Examples/Demo