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

1. #
Hans van der Meer
Engineering Manager Desktop Clients

2. #

3. #
• 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

4. #
• 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?

5. #
The product lifecycle is a steady flow,
from concept to implementation
Design
Prototype
Implementation
Testing
Maintenance
Analysis

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

7. #
• 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

8. #

9. #
• 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

10. #
• 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

11. #
• 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?

12. #
• 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

13. #
Embedded Team
Build
Initial Docs
Test & Confirm
Push
Functional Teams
Build Team
Documentation
Test
• Builds are now ‘Push First’, ‘Notify Later’
• One fix per push (deploying is cheap)

14. #
• 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

15. #
• 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)

16. #

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

18. #
• 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)

19. #
• 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/)

20. #
• 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”

21. #
RESOURCES
Webinar:
info.perforce.com/webinar-continuous-delivery-best-practices-revealed
Perforce adapting CD:
www.perforce.com/blog/140311/why-perforce-adopting-continuous-delivery

22. #
Han van der Meer
hans@perforce.com