Document

Transcript Document

Punishment Through Continuous Delivery

If it hurts, do it more often…

Typical Deployment Pipeline

Order the T-shirts for the Development team Announce availability Write the code Write the manual 5.

Hire a Product Manager Spec the software (writing the specs after the code helps to ensure that the software meets the specifications) Ship Test (the customers are a big help here) 9.

Identify bugs as potential enhancements 10.

Announce the upgrade program Source: http://www.nullskull.com/a/722/the-top-ten-rules-of-software-development.aspx

Monday is Deployment Day

What is Continuous Delivery and Why Do it?



Continuous Delivery

• A development practice which enables software to be deployed at any time • Software changes are delivered frequently and incrementally to the client • Relies upon automation and tooling to fulfill deployments consistently 

Continuous Deployment

• What is checked in and makes it through the delivery pipeline is immediately deployed to production • This results in many production deployments every day 

Why bother?

• Frequent delivery means fewer changes are made with each deployment, reducing both complexity and risk.

• Practice makes perfect 4

Assisted Parking vs. Manual Parking

Delivery Pipeline (example)

What are the benefits

 Push-of-the-button deployments / Less Stress • You say “oh, we deployed today?” vs. “we have a deployment this month”  Reduced Errors during deployments   Easy rollback Visible progress  Improved User Feedback  Improved Code Quality • Because you must use automated testing and CI to detect defects early 7

The Journey to Continuous Delivery

Continuous Delivery Continuous Integration Using Automated Tests Using Version Control

Demo: Version Control 101

Tips with Version Control

 Only check in working code  Work on small units of code   Check in several times per day

Only check in working code

  Do not use branches Before you check in: • • • • Build the software Run unit tests Update your local copy Build and Run again if changes were found 10

Unit Testing – Why bother?

Unit Tests – Exercising the Code

 Automated and Repeatable  Easy to Implement   Relevant for tomorrow Anyone can run them at the push of a button   Quick Consistent results   Isolated from other tests Failure or Success should be easy to detect Source: The art of Unit Testing, 2 nd Edition, Roy Osherove 12

Unit Tests



What to Test

•

Scalar Values

•

Row-wise changes

•

External Values



How to Test

•

Arrange

•

Act

•

Assert

Demo: Unit Tests

Refactoring

Continuous Integration



Continuous Integration

(CI) is a development practice that requires developers to integrate code into a shared repository several times a day. Each check-in is then verified by an automated build, allowing teams to detect problems early.

Demo: Continuous Integration

Demo: Continuous Delivery

Tips with Database Code

 Version Control Database Objects    Use SSDT  Use refactoring to • • Rename Change schemas Use Static Code Analysis Prefer changes that: • • • Are not destructive Are additive Do not cause data movement  Do Unit Testing  Automate Tests  Build before check in 18

Tips for CD

 What Changes for Developers • Deliver software even before it is ready to be used • Feature Flags • • • • Work on smaller pieces of code Check-in often Done = When its in production All environments are the same – no more manual deployments sideways • Everything in VC is deployed  Configuration Management • • • Environment Variables Registry Entries 3 rd Party tools (exe, dll)  Where to start?

• Automate One Thing • Choose an easy win but something useful  Some other Benefits • • • Constant Feedback Nothing is missing in Deployment CD represents some living documentation for your app 19

Thank You

Mark Wojciechowicz  http://anexinetbi.blogspot.com/  @MarkW_BI Learn More  www.thoughtworks.com/

continuous

integration

 http://martinfowler.com/bliki/ContinuousDelivery.html