Continuously Delivering: Compress the time from committed to consumed
Upcoming SlideShare
Loading in...5
×
 

Continuously Delivering: Compress the time from committed to consumed

on

  • 1,728 views

 

Statistics

Views

Total Views
1,728
Views on SlideShare
1,584
Embed Views
144

Actions

Likes
1
Downloads
48
Comments
0

6 Embeds 144

http://summit.atlassian.com 102
https://summit.atlassian.com 28
http://www.atlassian.com 7
https://wacdev.internal.atlassian.com 5
http://magnolia-staging.private.atlassian.com:8080 1
url_unknown 1

Accessibility

Categories

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.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • Explain: my team my mission prefer technical solutions Of all process changes – this is the best
  • Who uses CI?
  • All Hands Gestures!
  • Embedded Crowd
  • XHTML
  • How many people here dogfood?
  • Mention CI
  • Value always delivered
  • Value always delivered
  • Value always delivered
  • Value always delivered
  • Value always delivered
  • React more quickly to new opportunities Don’t need to wait on release boundaries Reallocate resources more easily
  • React more quickly to new opportunities Don’t need to wait on release boundaries Reallocate resources more easily
  • Value always delivered
  • Less integration pain
  • Value always delivered
  • Ask what the audience make up is Chrome is one example of CD infrastructure – although channel based, so not the same
  • Use XHTML as an example
  • Gestures!
  • Dependencies

Continuously Delivering: Compress the time from committed to consumed Continuously Delivering: Compress the time from committed to consumed Presentation Transcript

  •  
  • Continuously Delivering
  • Agenda
    • Existing Processes
    • Benefits of Continuous Delivery
    • Approaches to achieving Continuous Delivery
    • Atlassian Tools
  • Atlassian Process
    • Long lived feature branches for major features
    • 98 day releases
    • Feature integration
    • Hardening
      • 2 week beta
      • 2 week RC
  • What’s the problem?
  • Value Timeline Release Release to Studio Release of cross-product features Customer Upgraded
  • Large Releases
    • Unaddressed risk
      • Large changes
      • Support burden
      • Impacts development speed
    • No way to revert?
      • Need to double check everything
    • Large release anti-pattern
  • Branching
    • Extends time to delivery
    • Prevents iterative development
    • Increases big-bang
    • Merging pain
  • Everyone does CI, right?
    • Same reason as Continuous Integration
      • Don’t leave a manual, error-prone process to the end
  • Rapid Release Cycles
  • Dogfooding
    • Some are fortunate enough to use their own software
    • If you are, take advantage of it!
    • Find bugs, gather feedback
    • Instability won’t affect the customer
  • Regular Deployments
    • Company dogfooding server
      • Fortnightly
    • Team dogfooding server
      • Nightly
    • Stable releases
      • Fortnightly
  • Packaged Release Automation
    • SCM Tag
    • Maven upload
    • Release in JIRA
    • Release notes in Confluence
    • Push binaries to distribution
  • Continuous Delivery
  • Continuous Delivery
    • Produce a regular, deployable-to-production build
      • Regular probably means daily
    • Continuous Deployment would be to deploy each one
  • Why?
  • For Product…
  • No Features Waiting in Queue
  • Market New Releases “Whenever”
  • Great Momentum
    • Happy & Forgiving Customers
  • Small Changes, Immediate Validation
  • Rapid Iteration
    • Hit => Double Down
    • Miss => Revert
  • Agility
  • For Engineering…
  • Build what people want
  • Less Fragility
    • Less time waiting in queue
  • Smaller batches
    • Less integration pain
  • More Focus
  • Our Story…
  • Which may apply to you…
    • SaaS
    • Installed Product
    • Single Client
  • Progress Summary
    • Small Stories
    • Removed Branches
    • Accelerated Builds
    • Automated Deployment
  • Deployment Pipeline
    • Environments
      • Dogfooding
      • Homogeneous
    • Batched build pipeline
    • Smoke tests
    • Automated backup & rollback
  • Rapid Continuous Integration
    • Build Stages
      • Unit tests
      • UI tests
      • Functional tests
    • Batching
      • EC2
      • Bamboo
  • Deployment Speedup
    • Previously…
      • 1-2 days effort
      • Every 2 weeks
    • Now
      • 25min build, 15min deploy, zero downtime
      • Approx 10x / day
  • Bamboo Support
    • Tasks
    • Plan Variables
    • Parameterised Builds
    • Artifact Passing
    • Manual Stages (3.2)
  • Delivery Gates
    • Checkpoints are necessary
      • Just make sure they’re automated
    • Manual checkpoints exist due to fear
      • Often they can be removed with no tangible impact
      • Sometime possible to partially automate
  • Dark Features
    • No long-lived branches
    • Decouples deploy & launch
    • Reduces risk
  • Monitoring
    • Log file analysis
      • Splunk
    • Application instrumentation
      • Metrics
    • Runtime VM instrumentation
      • New Relic
  • Challenges
    • Scrum vs. Kanban
    • Downtime
    • Code & test discipline
      • Pre-commit reviews?
    • Change tracking
      • Release notes?
      • What environments have received a change?
  • Tips
    • Environment Independence
    • Modular Code
      • Or “Branch by Abstraction”
    • Version Everything
      • Especially the deploy scripts
    • Team Changes
      • QA
      • DevOps
  • Future
  • Extending the pipeline Team Company Studio Studio Studio
  • Issue-based Deployment
    • Smallest sensible chunk should be delivered
    • Used to be a whole release
      • Traditional Process
    • A feature?
      • Deployment after feature branch merges
    • A commit?
      • Deploy on green build
    • An issue?
  • Issue-based Deployment A B A C B D D B C B E B B B B master/default/trunk deployment branch
  • Summary
    • Commit -> Dogfooding
      • Time: 2 weeks to 30min
      • Frequency: Fortnightly to 10 times per day
    • It may require changes to existing processes
    • Atlassian tools are currently easy to automate
    • Continuous Delivery is a first-class feature of Bamboo
    • Stay tuned for more help from Atlassian
  • Questions?
  • More Information
    • Bamboo 3.2
    • http://atlassian.com/sotware/bamboo
    • Atlassian Dev Blog
    • http://blogs.atlassian.com/developer
    • Recorded Summit Sessions
    • http://summit.atlassian.com