continuous delivery overview

CONTINUOUS DELIVERY Will Iverson, CTO Michael McIntosh, Dir. Business Development

Agenda

• Who are you? • Who is Dynacron Group? • What is Con>nuous Delivery?

• What pains does this solve?

• Why It Ma@ers (By Role) • Drill down on a few topics/examples

• Next Steps • Q & A

Who Are You?

• Technology Manager •  Technology Implementer

Who Are We?

• Dynacron Group •  Based in Kirkland, WA •  Founded in 2010 •  ~25 Consultants, ~30 Total Staff • www.DynacronGroup.com

What is Continuous Delivery?

• Con>nuous Delivery (CD) is: •  a set of principles and prac>ces in growing use in soYware development to improve the process of soYware delivery.

•  Techniques such as automated tes>ng, con>nuous integra>on and automated deployments allow soYware to be developed to a high standard and easily packaged and deployed to test environments.

•  This results in the ability to rapidly, reliably and repeatedly push out enhancements and bug fixes to customers at low risk and with minimal manual overhead.

* Wikipedia Definition

TODAY’S GOALS

I want to know about continuous Delivery because…!

Pain & Opportunities •  Tell me what’s involved in doing a release?

•  How long does it take? •  How many steps are involved? •  How successful is the process? •  How oYen do you do them? •  Do you have “heroes”? •  What would happen if a par>cular environment disappeared/melted down?

•  Do your environments match? •  How quickly can you build an environment? •  How hard is it to do a patch? A major release?

Current State of Affairs

Current State Problem Summarized

• Key Pain Points: •  Painful releases •  Inability to predict delivery affec>ng business commitments • Deployment to environments •  Code quality •  Environment configura>on & management •  Expensive, >me consuming manual QA (unable to build lab) •  Par>al Agile implementa>on (Scrum but no technical processes)

Why?

• What are some of the causes of these pain points?

Target State

•  Commitments between teams & functional areas are automated & tracked in systems

•  Teams use fast automation instead of slow manual processes

So… Why Not? • New Tools

•  Maven/MSBuild/etc, N/JUnit, Jenkins/Hudson/TeamCity/TFS, Selenium, SauceLabs, Puppet/MS Config Mgr…

• New Processes •  Where do I get builds?

• Organiza>onal Impact •  Cross-‐func>onal manager buy-‐in

• New Designs •  Stateless systems •  Environments from tools, not manual

•  Iner>a •  Comfort

Stuff To Learn Project

Management QA/SDET Development IT/Ops/DevOps

Agile (Scrum/Kanban/XP) u u u u

Unit Testing u u

Functional/Web Testing u /u

Test-Driven Development u u

Continuous Integration u u

Binary Repository u u u

Distributed Version Control (e.g. Git) u u

Stateless Architecture u u

Environment (Cloud/Virtual) u

= Understand Concepts u = Understand Technical Implementation

Project Manager’s View

• Agile •  Itera>ve, reduce risk…

• Unit/Func>onal/TDD •  If requirement exists in a test, you won’t have to worry about regressions

•  Full regression suite run in minutes, not hours/days

• Con>nuous Integra>on •  Solidifies ongoing work meaning of “Done”

• Binary Repository •  Radically simplifies release meaning of “Done”

Example: Automated Traceability

•  Story wri@en & tracked in backlog tool •  e.g. Story #25431 in Rally

•  Story is mapped to automated tests •  Tests are roughed out as WIP automated tests, checked in with Story #25431

•  Story is implemented by development •  Code checked in with Story #25431

•  Story is referenced by automa>cally generated release notes & bundled into build •  Build #456 has Story #25431 •  Ready for release – just send an email “Promote #456 to shared QA”

•  Everything automated & traceable

QA/SDET View

• Biggest shiY is moving from manual regression to automa>on • New tools & skills •  Vastly improved produc>vity

• Other key changes •  Automa>ng produc>on of builds vastly reduces stress • Move from fire-‐figh>ng

Example: Selenium

Example: SauceLabs

•  Instant QA Lab •  50-200 machine build? •  Video & screenshots for easy sharing

•  Parallel Test Execution •  e.g. 200 tests x 5 browsers = 1000 tests •  Run 50 parallel threads = complete in 15

minutes

Developer’s View

• Spend a LOT more >me wri>ng GOOD code • Comfortable refactoring

•  Know that your refactoring is not breaking things •  Know that you can fix technical debt

• Never hear “works on my machine” again • Never have to sit wai>ng for a build/release/manual test pass

• Clear, established standards for defini>on of done

Example: Binary Repository

The image cannot be displayed. Your computer may not have enough memory to open the image, or the image may have been corrupted. Restart your computer, and then open the file again. If the red x still appears, you may have to delete the image and then insert it again.

Continuous Integration

Server

Binary Repository Compiled

Code Applications

Source

Libraries

QA

Stage

Prod

Developers

Source Control

Source

Reference Build & Test Server Runs tests before committing to source control. Stores all

release artifacts

All work tracked, versioned

All builds reproducible. Code matches release. Enforces a standard build, test & release environment. Broken builds notify developer immediately without breaking build.

Vastly reduces wait time. Standardizes work product.

IT/Ops View

• Releases are solid, every >me • Releases are always in the same place • Releases have excellent documenta>on

• Most of which is machine generated, so it’s always current & up to date

• Configura>on systems instead of tribal knowledge means you can actually go on vaca>on

• Solid, stateless releases can go out during normal business hours, so you can enjoy evenings & weekends

Example: Simplified Releases

Binary Repository

Applications QA Stage Prod Stores all release artifacts

Applications Applications

Centralized Virtual Environments / Private Cloud

Versioned Configuration



Configuration Management System

NEXT STEPS How do we get started?

Starting Points

• Plaoorm Moderniza>on •  Incremental Rolling Upgrade •  Take exis>ng applica>on[s], upgrade to new plaoorm •  Pro: No requirements churn

•  Goes much faster than you would expect

•  Con: S>ll need to >e into business ini>a>ve (new L&F?)

• New Applica>on[s] •  Pro: Build new func>onality with a clean start •  Con: S>ll have legacy environment to maintain

Typical Engagement •  Assessment

•  Gap analysis between current systems and target state •  Applica>on Inventory •  Tool recommenda>ons

•  Training •  Group learning •  Execu>ve & Management Baselines Established

•  Execu>on •  Combine with business-‐value project for paired implementa>on •  Typically a replaoorming or new project

•  Best bang for buck: Clean up old systems & code first •  Convert exis>ng manual tests to automa>on, modernized build/release, convert to stateless

Partner Attributes

• Exis>ng people, process & tools • Established architecture & infrastructure • Experience with hands on implementa>on • Training & pairing for long term rela>onship

•  Local, hybrid team engagements

• Reference accounts