• Save
Continuous Delivery
Upcoming SlideShare
Loading in...5

Continuous Delivery






Total Views
Views on SlideShare
Embed Views



7 Embeds 1,553

http://jug.lv 1545
http://abtasty.com 3
http://www.google.com 1
http://webcache.googleusercontent.com 1
http://translate.googleusercontent.com 1
https://www.google.lv 1
https://www.google.com 1



Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment
  • When business come to you and say you’re releasing too frequently – you’re on the right way.
  • Short Lead time  fasterFeedbackCD is expensive. Leanisabout WASTE not COST. High long-term ROI.Increases motivation, as you get things done faster, less stress
  • Большинство– тормозы. Неэффективность процесса и ОПАСНОСТЬ.
  • The most complex task is push button.
  • Create environment where people get responsible for consequence of their action and they will care (DevOpsphylosophy)
  • - Modules / services / entities / staticcontent
  • Whybranches? Parallelization. Multipleversionsoftheapp.Unability to keepapplicationstableduringdevelopment.Onegoal, extracare. No merges. Oneversion, pushupteamsforsynchronizationBringspainforward, raisesprofessionalismIsolationillusion
  • If people have to use feature branch, something is wrong with your architecture.
  • 3WReduce TTD (Time to detect), TTR (Time to recover)
  • Practice makes perfect. Toyota way.
  • CD is hard. Process flaws become visible.

Continuous Delivery Continuous Delivery Presentation Transcript

  • Continuous DeliveryHelping your business win by bringing the pain forward
  • Agenda• Introduction• Deployment pipeline• User disruption• Anti-patterns• Adoption• Tools• Conclusion• Q&A
  • Introduction
  • Our highest priority is to satisfy the customer throughearly and continuous delivery of valuable software.Agile Manifesto
  • What is continuous delivery?Agile methodology for reducing the cost, time and risk ofdelivering incremental changes to users.
  • Inspired by Lean Startup
  • Deliver the right thing. Frequently.
  • «You can’t just ask customers what they wantand then try to give that to them.By the time you get it built, they’ll wantsomething new.»
  • So how frequently?Deliver fast-enough so that a customer didn’t have timeto change their mind.
  • Goals- Build the right thing (MVP, eliminate waste)- Reduce lead time (reduce WiP, eliminate bottlenecks)- Reduce cost (optimize, automate)- Reduce risk (resilience built-in, small increments)Continuously:
  • Who does continuous delivery?
  • Let’s rock.
  • Redefine «Done»Coded Reviewed Checked-in Built Tested DemoedReleased to end-user.
  • How long would it take your organization to deploy achange that involved just one single line of code?Do you do this on a repeatable, reliable basis?Mary & Tom PoppendieckImplementing Lean Software DevelopmentDetermine cycle time
  • Reduce risk of release« If it hurts, do it more frequently »
  • How?
  • By implementing end-to-end automation ofbuild, deploy, test and release processes.
  • The Deployment Pipeline
  • A pull system spanning full product cycle.- Fully automated (with push button approvals)- Visible- Measurable- Parallelizable
  • Build only once.
  • Deploy the same way to every environment.
  • Fail fast.
  • Automate everything (almost).
  • Build quality in.
  • Keep code always releasable.
  • Treat every version is a release candidate.Contradicts with traditional approaches.
  • Quality goes up.People care.
  • Version everything.Single version. No major/minor/patch increments.
  • Version control everything.Code, Configuration, Infrastructure…
  • Test excessively.
  • Provide recovery plan.
  • Measure.
  • - Small increments- Deploy components independently- Leave backward compatibilityAvoid «Big Bang» releases
  • Avoid branches- True Continuous Integration - work only in mainline- No feature branches- No release branches
  • «Feature branching is apoor man’s modular architecture»Dan BodartBuild a modular platform of micro-services.
  • Make no exceptionsEven urgent production fix should pass the samedeployment pipeline.
  • User disruption
  • downtime deployments0
  • Blue - Green deployment
  • Deployment is not a Release.Release is a marketing decision.
  • Smoke test deployment.Release only after that.
  • Feature Toggles
  • Branch by AbstractionMultiple versions in a single code base.
  • Backward compatibility is a key.State is pain in the ass, but remediable with redundancy
  • Canary releasingRelease to a subset of users.
  • Anti-Patterns
  • Code Freeze ceremony
  • Deployment rarely / lateAvoid late contact with reality.
  • Manual environment configuration
  • Privileged deploy team
  • Not repeatable process
  • Slight differences
  • Manual deploymentsSleep well. Forget 2.00 AM deployments.
  • Hard to track
  • Adoption
  • Forget special «Continuous Delivery» projects
  • noun1 a feeling of fear or agitation about something that may happen: themen set off in fear and trepidation.2 trembling motion.Embrace changetrepidation | trep·i·da·tion
  • Raise confidence thatChange can be safe enough.
  • Do not be afraid to fail.Learn what doesn’t work first, then see how to make it better.
  • Continuously improveJapanese for "improvement", or "change for the better"Refers to philosophy or practices that focus upon continuousimprovement of processes in manufacturing, engineering, and businessmanagement.Kaizen | 改善
  • Find the right team and start kicking ass.
  • Tools
  • Versioning
  • Build & dependency management
  • CI + Pipelining
  • AutomationInfrastructure Script streamliningGlu CapistranoDB migrations
  • ATDD + Living documentation
  • Monitoring
  • Micro-services?
  • Conclusion
  • Continuous Delivery challengesyour engineering skills.Are you ready to accept the challenge?
  • Thank you!