Continuous Development: Supporting a Release Model
Download as PPTX, PDF1 like690 views
The document discusses Hans van der Meer's insights on moving the P4V software into a continuous delivery (CD) model, emphasizing the importance of effective testing and customer feedback. It outlines the strategies for process improvement and automation in software deployment while highlighting the benefits and potential pitfalls of CD practices. The presentation also covers the maintenance of legacy code, product quality improvement, and the transition to regular updates without accumulated patches.
Continuous Development: Supporting 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 [email protected]