22
# Hans van der Meer Engineering Manager Desktop Clients Continuous Development, Supporting a Release Model

Continuous Development: Supporting a Release Model

Embed Size (px)

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

Page 1: Continuous Development: Supporting a Release Model

#

Hans van der MeerEngineering Manager Desktop Clients

Continuous Development, Supporting a Release Model

Page 2: Continuous Development: Supporting a Release Model

#

Technical Product ManagerDesktop Clients

Perforce Software

Page 3: Continuous Development: Supporting a Release Model

#

• 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

Page 4: Continuous Development: Supporting a Release Model

#

• 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

Page 5: Continuous Development: Supporting a Release Model

#

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

Waterfall Philosophy

Design

Prototype

Implementation

Testing

Maintenance

Analysis

Page 6: Continuous Development: Supporting a Release Model

#

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

Scrum Philosophy

Page 7: Continuous Development: Supporting a Release Model

#

• 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

Page 8: Continuous Development: Supporting a Release Model

#

Continuous Delivery for P4V 14.2

Page 9: Continuous Development: Supporting a Release Model

#

• 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?

Page 10: Continuous Development: Supporting a Release Model

#

• 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?

Page 11: Continuous Development: Supporting a Release Model

#

• 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

Page 12: Continuous Development: Supporting a Release Model

#

• 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

Page 13: Continuous Development: Supporting a Release Model

#

• 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

Page 14: Continuous Development: Supporting a Release Model

#

• 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

Page 15: Continuous Development: Supporting a Release Model

#

• 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

Page 16: Continuous Development: Supporting a Release Model

#

Quick Automation with Sikuli

Page 17: Continuous Development: Supporting a Release Model

#

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

Our Flavors of Product Verification

Page 18: Continuous Development: Supporting a Release Model

#

• 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

Page 19: Continuous Development: Supporting a Release Model

#

• 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

Page 20: Continuous Development: Supporting a Release Model

#

• 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?

Page 21: Continuous Development: Supporting 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

Page 22: Continuous Development: Supporting a Release Model

##

Thank you!Han van der Meer

[email protected]