Continuous Development: Supporting a Release Model

Preview:

DESCRIPTION

This talk will explore whether Continuous Delivery as a methodology is applicable, even when the product delivery still requires a release model.

Citation preview

#

Hans van der MeerEngineering Manager Desktop Clients

Continuous Development, Supporting a Release Model

#

Technical Product ManagerDesktop Clients

Perforce Software

#

• About the speaker and about P4V• Philosophy “elevator pitch” of Development

Practices• Our approach moving P4V to CD• It is all about testing• Tying it together• How our customers will benefit• Q & A

Agenda

#

• Been around and … seen my share of Software Development practices, so has P4V

• This talk is about P4V's dive into CD– How did we take it on?– Where are we now?– Will the customer see a difference?

About the Speaker and About P4V

#

The product lifecycle is a steady flow, from concept to implementation

Waterfall Philosophy

Design

Prototype

Implementation

Testing

Maintenance

Analysis

#

• Anticipate change• Define small deliverables• One sprint at a time• Issues are always evolving• Teams organize themselves• Daily standups

Scrum Philosophy

#

• Focus on improving process• Fine-tune deployment pipeline• Continuous deployment

– Test the product effectively– Deploy all the time– Remove roadblocks– Gather feedback often and early

• Automate as much as you can

Continuous Delivery Philosophy

#

Continuous Delivery for P4V 14.2

#

• Contains legacy code• Desktop UI product • Multi-platform• Elaborate: Does many things in many different ways• Customers choose when to upgrade.

Early adoption?• No plans to abandon the Release Model

What Kind of Product is P4V?

#

• Speed up the delivery of fixes in our release lines• Promote ‘Early adoption’• Improve the Quality of the product

– Guarantee consistency and rapid delivery by automating what is repetitive

– ‘Ease of release’ will free up time for more testing and development

Why Continuous Delivery for P4V?

#

• An upside-down look at CD• What are our goals? / How can we get there?

– Where can we fine-tune deployment pipeline?– What gives us the best ROI?– Where does CD make most sense?– How to be confident assuming a short turnaround?

Our Approach Moving P4V to CD

#

• Mainline vs Release Branches– Release Branch

• Push every fix as soon as possible• Eliminate the red tape where you can

– Mainline• Support regular snapshots• Deployable at all times

Where Does CD Make Sense

#

• Builds are now ‘Push First’, ‘Notify Later’• One fix per push (deploying is cheap)

The Release Branch Red Tape

BuildInitial Docs

Test & ConfirmPush

Embedded Team

Test

Documentation

Build Team

Functional Teams

#

• Exploratory testing– Gain a thorough understanding– Make the Software really work– Find bugs

• Formalize your test– Make sure you can repeat it and write it down

• Automate it if you can

The Lifecycle of a UI Test

#

• Squish (High maintenance)– Intelligent recording and playback– Object recognition– Generates scripts to run

• Sikuli (Low maintenance)– Identifies GUI elements using image recognition– Simple python scripts (no recording)

Automated Testing Our UI

#

Quick Automation with Sikuli

#

• Exploratory testing• Unit tests• API regression tests• Performance tests• Coverity• Manual testing• Automated test suite

Our Flavors of Product Verification

#

• Automated tests (Sikuli)– Jenkins– Results posted

• Performance tests (Squish)– Staged machines (Cron jobs)– Result saved in Perforce

• Builds– Electric Commander– Staged environments (on build machines)

Tying it Together

#

• Upcoming releases– No accumulated patch releases, every fix is now a patch– Fix it, push it, then let everybody know

The Development Branch (upcoming release)– The release is always deployment ready– Push out snapshots regularly to ftp for customers– Get customer feedback while developing the product

(latest P4V snapshot : ftp://ftp.perforce.com/perforce/snapshot/p4v/)

How Our Customers Will Benefit

#

• Benefits– CD forces you to analyze and improve your pipelines– You can focus more on Exploratory testing when

bumping up Automated testing

• Pitfalls– False security, when only relying on automated testing– Aim for “Quality trumps any methodology”

CD in a Release Model?

#

RESOURCESWebinar:info.perforce.com/webinar-continuous-delivery-best-practices-revealed

Perforce adapting CD: www.perforce.com/blog/140311/why-perforce-adopting-continuous-delivery

##

Thank you!Han van der Meer

hans@perforce.com

Recommended