Continuous Delivery techniques and practices are often misunderstood. This session will explore some Continuous Delivery anti-patterns based on work 'in the wild' with a wide range of organisations across different industry sectors: - Believing that "Continuous Delivery is not for us" - Ignoring the database - Thinking that a deployment pipeline is just a series of chained jobs in Jenkins - Not measuring delays between value-add activities - Ignoring Cost-of-Delay and job size - Not funding the build/test/deployment capability properly By avoiding these pitfalls, we can increase the effectiveness of our software delivery efforts. Attendees will learn: 1. Why Continuous Delivery (CD) is useful for almost all modern software 2. How to approach CD for databases 3. How to make CD really 'fly' within the organisation 4. How to 'sell' CD to business stakeholders

1. Continuous Delivery Anti-patterns
from the wild
Thursday 6th October 2016 - #IPEXPO
Matthew Skelton
Skelton Thatcher Consulting
@matthewpskelton

3. anti-patterns

4. Matthew Skelton
@matthewpskelton

5. Continuous Delivery / …
30+ organisations
UK, US, EU, India, China

7. DevOpsTopologies.com

9. anti-patterns

10. 1. Not reading the
‘Continuous Delivery’
book

11. “What book?”

12. Keep Everything in Version Control
Done Means Released
Don’t Check In on a Broken Build
Never Go Home on a Broken Build
Fail the Build for Slow Tests
Only Build Your Binaries Once
Deploy the Same Way to Every Environment

14. Use the Humble &
Farley book on
Continuous Delivery

15. 2. Long and slow
deployment pipelines

17. 40+ steps between code
commit and release
several weeks’ duration
BUT
bug fixes in 4 steps

21. Short, wide pipelines
http://continuousdelivery.com/2010/09/deployment-pipeline-anti-patterns/

22. 3. “Continuous Delivery
is not for us”

24. October 29, 2015
Sarah Goff-Dupont
@DevToolSuperFan

25. “Nope.
CD is fine for some
systems/teams/software,
but each company should
make their own business
decisions about how often
to release code.”
(Why every development team needs
continuous delivery)

26. “…each company should make their own business
decisions about how often to release code…”
err, this is exactly what we get with
Continuous Delivery practices!

27. Continuous Delivery !=
Continuous Deployment
(Pull vs Push)

28. Continuous Delivery does not
need deployments straight to
Production systems

29. Continuous Delivery does not
need cloud servers or
containers

30. Continuous Delivery is not
100 deployments per day

32. Copyright © O’Reilly Media 2016

33. Continuous Delivery is a set of
excellent practices for building
working software systems

34. Deliver to a simulation
environment if not
Production

35. 4. No effective logging
or application metrics

40. use logging as a
channel/vector to
make distributed
systems more testable

41. Aggregated logging +
detailed metrics drive
decision-making

42. 5. No investment in
build & deployment

47. versioning approaches
interdependencies
evaluation of new techniques
splitting / joining components
infrastructure availability

48. Approx 1 x FTE per
Product Team for
build & deployment

49. 6. Operational aspects
not addressed well

50. ‘Functional’
‘Non-
functional’

52. ‘Operational Features’
(not NFRs)

53. FEATURES
Visible
Operational
Visible

54. Single backlog for
visible and operational
features

55. 7. Forgetting the
database

61. ApexSQL
ActiveRecord (and similar)
DbMaestro
FluentMigrator
Flyway
Liquibase
Redgate tools
Vendor-native (e.g. EF, SSDT)

62. Use a tool for DB
changes + drive from
version control

63. 8. “Just plug in a
deployment pipeline”

65. Limited unit tests
No re-architecture
1 Ops person for 25 techies
Opaque component names
No logging or metrics

66. Re-architect for
Continuous Delivery

67. 9. Container envy
(aka microservices envy)

69. No unit or integration tests
No logging or monitoring
200+ ETL jobs only in Prod
DB on a single node (no HA!)
Limited Dev+Ops collaboration

71. Adopt good CD
practices before adding
container complexity

72. Not reading any of ‘Continuous Delivery’ book
Long and slow deployment pipelines
“Continuous Delivery is not for us”
No effective logging or application metrics
No investment in build & deployment
Operational aspects not addressed well
Forgetting the database
“Just plug in a deployment pipeline”
Container envy

73. Use the CD book
Short, wide pipelines
Deliver to a simulation environment
Aggregated logging + metrics
Explicitly fund build & deployment
Single backlog for all features
Use a tool for DB changes + version control
Re-architect for Continuous Delivery
Adopt good practices before using containers

74. Questions?

75. References
‘Continuous Delivery’ by Jez Humble & Dave Farley, 2010
https://www.amazon.co.uk/Continuous-Delivery-Deployment-Automation-Addison-
Wesley/dp/0321601912/
‘Deployment Pipeline anti-patterns’ by Jez Humble
http://continuousdelivery.com/2010/09/deployment-pipeline-anti-patterns/
‘Why every development team needs continuous delivery’ by Sarah Goff-Dupont [Atlassian]
http://blogs.atlassian.com/2015/10/why-continuous-delivery-for-every-development-team/
‘Continuous Delivery with Windows and .NET’ by Chris O’Dell & Matthew Skelton, O’Reilly, 2016
http://cdwithwindows.net/
‘Database Lifecycle Management’ by Grant Fritchey and Matthew Skelton, Redgate, 2016
http://thedlmbook.com/

76. Thank you
http://skeltonthatcher.com/
enquiries@skeltonthatcher.com
@SkeltonThatcher
+44 (0)20 8242 4103
@matthewpskelton