Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.
Continuous Delivery Anti-patterns
from the wild
Wednesday 18th May 2016 - #IPEXPO
Matthew Skelton
Skelton Thatcher Consult...
anti-patterns
Matthew Skelton
@matthewpskelton
Continuous Delivery / …
30+ organisations
UK, US, EU, India, China
DevOpsTopologies.com
anti-patterns
1. Not reading the
‘Continuous Delivery’
book
“What book?”
Keep Everything in Version Control
Done Means Released
Don’t Check In on a Broken Build
Never Go Home on a Broken Build
Fa...
Use the Humble &
Farley book on
Continuous Delivery
2. Long and slow
deployment pipelines
40+ steps between code
commit and release
several weeks’ duration
BUT
bug fixes in 4 steps
Short, wide pipelines
http://continuousdelivery.com/2010/09/deployment-pipeline-anti-patterns/
3. “Continuous Delivery
is not for us”
October 29, 2015
Sarah Goff-Dupont
@DevToolSuperFan
“Nope.
CD is fine for some
systems/teams/software,
but each company should
make their own business
decisions about how oft...
“…each company should make their own business
decisions about how often to release code…”
err, this is exactly what we get...
Continuous Delivery !=
Continuous Deployment
(Pull vs Push)
Continuous Delivery does not
need deployments straight to
Production systems
Continuous Delivery does not
need cloud servers or
containers
Continuous Delivery is not
100 deployments per day
Copyright © O’Reilly Media 2016
Continuous Delivery is a set of
excellent practices for building
working software systems
Deliver to a simulation
environment if not
Production
4. No effective logging
or application metrics
use logging as a
channel/vector to
make distributed
systems more testable
Aggregated logging +
detailed metrics drive
decision-making
5. No investment in
build & deployment
versioning approaches
interdependencies
evaluation of new techniques
splitting / joining components
infrastructure availab...
Approx 1 x FTE per
Product Team for
build & deployment
6. Operational aspects
not addressed well
‘Functional’
‘Non-
functional’
‘Operational Features’
(not NFRs)
FEATURES
Visible
Operational
Visible
Single backlog for
visible and operational
features
7. Forgetting the
database
ApexSQL
ActiveRecord (and similar)
DbMaestro
FluentMigrator
Flyway
Liquibase
Redgate tools
Vendor-native (e.g. EF, SSDT)
Use a tool for DB
changes + drive from
version control
8. “Just plug in a
deployment pipeline”
Limited unit tests
No re-architecture
1 Ops person for 25 techies
Opaque component names
No logging or metrics
Re-architect for
Continuous Delivery
9. Container envy
(aka microservices envy)
No unit or integration tests
No logging or monitoring
200+ ETL jobs only in Prod
DB on a single node (no HA!)
Limited Dev+...
Adopt good CD
practices before adding
container complexity
Not reading any of ‘Continuous Delivery’ book
Long and slow deployment pipelines
“Continuous Delivery is not for us”
No ef...
Use the CD book
Short, wide pipelines
Deliver to a simulation environment
Aggregated logging + metrics
Explicitly fund bui...
Questions?
References
‘Continuous Delivery’ by Jez Humble & Dave Farley, 2010
https://www.amazon.co.uk/Continuous-Delivery-Deployment...
Thank you
http://skeltonthatcher.com/
enquiries@skeltonthatcher.com
@SkeltonThatcher
+44 (0)20 8242 4103
@matthewpskelton
Continuous Delivery antipatterns from the wild - Matthew Skelton - IPEXPO Manchester 2016
Continuous Delivery antipatterns from the wild - Matthew Skelton - IPEXPO Manchester 2016
Continuous Delivery antipatterns from the wild - Matthew Skelton - IPEXPO Manchester 2016
Continuous Delivery antipatterns from the wild - Matthew Skelton - IPEXPO Manchester 2016
Continuous Delivery antipatterns from the wild - Matthew Skelton - IPEXPO Manchester 2016
Continuous Delivery antipatterns from the wild - Matthew Skelton - IPEXPO Manchester 2016
Continuous Delivery antipatterns from the wild - Matthew Skelton - IPEXPO Manchester 2016
Continuous Delivery antipatterns from the wild - Matthew Skelton - IPEXPO Manchester 2016
Continuous Delivery antipatterns from the wild - Matthew Skelton - IPEXPO Manchester 2016
Continuous Delivery antipatterns from the wild - Matthew Skelton - IPEXPO Manchester 2016
Continuous Delivery antipatterns from the wild - Matthew Skelton - IPEXPO Manchester 2016
Continuous Delivery antipatterns from the wild - Matthew Skelton - IPEXPO Manchester 2016
Continuous Delivery antipatterns from the wild - Matthew Skelton - IPEXPO Manchester 2016
Continuous Delivery antipatterns from the wild - Matthew Skelton - IPEXPO Manchester 2016
Continuous Delivery antipatterns from the wild - Matthew Skelton - IPEXPO Manchester 2016
Continuous Delivery antipatterns from the wild - Matthew Skelton - IPEXPO Manchester 2016
Continuous Delivery antipatterns from the wild - Matthew Skelton - IPEXPO Manchester 2016
Continuous Delivery antipatterns from the wild - Matthew Skelton - IPEXPO Manchester 2016
Continuous Delivery antipatterns from the wild - Matthew Skelton - IPEXPO Manchester 2016
Continuous Delivery antipatterns from the wild - Matthew Skelton - IPEXPO Manchester 2016
Continuous Delivery antipatterns from the wild - Matthew Skelton - IPEXPO Manchester 2016
Continuous Delivery antipatterns from the wild - Matthew Skelton - IPEXPO Manchester 2016
Continuous Delivery antipatterns from the wild - Matthew Skelton - IPEXPO Manchester 2016
Continuous Delivery antipatterns from the wild - Matthew Skelton - IPEXPO Manchester 2016
Continuous Delivery antipatterns from the wild - Matthew Skelton - IPEXPO Manchester 2016
Continuous Delivery antipatterns from the wild - Matthew Skelton - IPEXPO Manchester 2016
Continuous Delivery antipatterns from the wild - Matthew Skelton - IPEXPO Manchester 2016
Prochain SlideShare
Chargement dans…5
×

3

Partager

Télécharger pour lire hors ligne

Continuous Delivery antipatterns from the wild - Matthew Skelton - IPEXPO Manchester 2016

Télécharger pour lire hors ligne

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.

Livres associés

Gratuit avec un essai de 30 jours de Scribd

Tout voir

Continuous Delivery antipatterns from the wild - Matthew Skelton - IPEXPO Manchester 2016

  1. 1. Continuous Delivery Anti-patterns from the wild Wednesday 18th May 2016 - #IPEXPO Matthew Skelton Skelton Thatcher Consulting @matthewpskelton
  2. 2. anti-patterns
  3. 3. Matthew Skelton @matthewpskelton
  4. 4. Continuous Delivery / … 30+ organisations UK, US, EU, India, China
  5. 5. DevOpsTopologies.com
  6. 6. anti-patterns
  7. 7. 1. Not reading the ‘Continuous Delivery’ book
  8. 8. “What book?”
  9. 9. 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
  10. 10. Use the Humble & Farley book on Continuous Delivery
  11. 11. 2. Long and slow deployment pipelines
  12. 12. 40+ steps between code commit and release several weeks’ duration BUT bug fixes in 4 steps
  13. 13. Short, wide pipelines http://continuousdelivery.com/2010/09/deployment-pipeline-anti-patterns/
  14. 14. 3. “Continuous Delivery is not for us”
  15. 15. October 29, 2015 Sarah Goff-Dupont @DevToolSuperFan
  16. 16. “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)
  17. 17. “…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!
  18. 18. Continuous Delivery != Continuous Deployment (Pull vs Push)
  19. 19. Continuous Delivery does not need deployments straight to Production systems
  20. 20. Continuous Delivery does not need cloud servers or containers
  21. 21. Continuous Delivery is not 100 deployments per day
  22. 22. Copyright © O’Reilly Media 2016
  23. 23. Continuous Delivery is a set of excellent practices for building working software systems
  24. 24. Deliver to a simulation environment if not Production
  25. 25. 4. No effective logging or application metrics
  26. 26. use logging as a channel/vector to make distributed systems more testable
  27. 27. Aggregated logging + detailed metrics drive decision-making
  28. 28. 5. No investment in build & deployment
  29. 29. versioning approaches interdependencies evaluation of new techniques splitting / joining components infrastructure availability
  30. 30. Approx 1 x FTE per Product Team for build & deployment
  31. 31. 6. Operational aspects not addressed well
  32. 32. ‘Functional’ ‘Non- functional’
  33. 33. ‘Operational Features’ (not NFRs)
  34. 34. FEATURES Visible Operational Visible
  35. 35. Single backlog for visible and operational features
  36. 36. 7. Forgetting the database
  37. 37. ApexSQL ActiveRecord (and similar) DbMaestro FluentMigrator Flyway Liquibase Redgate tools Vendor-native (e.g. EF, SSDT)
  38. 38. Use a tool for DB changes + drive from version control
  39. 39. 8. “Just plug in a deployment pipeline”
  40. 40. Limited unit tests No re-architecture 1 Ops person for 25 techies Opaque component names No logging or metrics
  41. 41. Re-architect for Continuous Delivery
  42. 42. 9. Container envy (aka microservices envy)
  43. 43. 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
  44. 44. Adopt good CD practices before adding container complexity
  45. 45. 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
  46. 46. 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
  47. 47. Questions?
  48. 48. 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/
  49. 49. Thank you http://skeltonthatcher.com/ enquiries@skeltonthatcher.com @SkeltonThatcher +44 (0)20 8242 4103 @matthewpskelton
  • uzy_exe

    Jul. 2, 2016
  • matthewskelton

    May. 18, 2016
  • SkeltonThatcher

    May. 18, 2016

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.

Vues

Nombre de vues

4 245

Sur Slideshare

0

À partir des intégrations

0

Nombre d'intégrations

204

Actions

Téléchargements

4

Partages

0

Commentaires

0

Mentions J'aime

3

×