Download to read offline
Uploaded byŽilvinas Kuusas
Continuous delivery
This document discusses the benefits of continuous delivery for software development. It advocates splitting large projects and tasks into smaller chunks that individual developers can complete in a day, including writing code, tests, reviews, and deployment. This allows work to be distributed among team members and delivered to production rapidly through an automated process. It emphasizes the importance of atomic commits, easy reviewability, testing, and deployability to ensure high quality and reduce risks. Frequent, reliable delivery allows for quick feedback and maximizes business value.
Continuous delivery
- 1. Continuous Delivery praktika irnauda 2017-11-09 VilniusPHP 0x3C Žilvinas Kuusas
- 2. Žilvinas Kuusas lead developer Estina/ ISIGN.io Twitter: @kuusas Email: zilvinas@kuusas.lt
- 3. 2nd of december,2017
- 4. Continuous delivery Release valuable andreliable software FAST
- 5. Speed === €€€* * € - the unit to measure the business value
- 6. 10 mins Client Givingsome requirements Developer Writing some lines of code FTP Deployment process * * triggered “on file save” PROD It’s DONE! Fast delivery
- 7. What can possiblygo wrong? ¯_(ツ)_/¯
- 8. The bigger yourproject grows - more problems you get ● ISIGN ○ 3 products ○ X shared components ● Needs ○ Deploy any time, any version Where it all began?
- 9. Managing risks ● Identifythe main project risks ○ Buggy deployments ■ Availability ○ Software quality ● Risk mitigation ○ Automated tests ○ Deployment process ■ Deploy to staging ■ Schema migrations ■ Rollbacks
- 10. Business Says “I NEEDSTUFF” Developer Writes few lines of code, some lines of tests. DONE! BIG AND Mr. Jenkins territory SCARY PROCESS Operations guy “scripts” PROD Finally, it’s available on prod! DONE DONE! I write code, aaaand it’s done!
- 11. Is it “done”or is it “done done”?
- 12. Everybody should beresponsible for delivered result
- 13. It is doneonly when it is DEPLOYED
- 14. Identifying issues ● Developer’sDONE doesn’t correlate with business expectations ● Developer is not familiar with the automated process ● Code reviews takes a lot of time ● Operations guy doesn’t know what developers are doing ● And we have translations guy! We can call him John. He knows nothing.
- 15. Developer deploys using automated scripts! Teameffort - from the beginning to the end Business Says “I NEED STUFF” Developer Writes few lines of code, some lines of tests! Testing Mr. Jenkins runs tests Code reviews Deployment PROD It’s DONE!
- 16. Integrating team membersinto the process ● Communication ● Responsibility boundaries ● Everybody has to know what he is doing
- 17. Orchestrating the deliveryprocess ● Atomic tasks ● Atomic commits ● Easy to read ● Easy to review ● Easy to test ● Deployable to prod
- 18. Don’t postpone, mergeit! ● Avoid long living branches ● Avoid versioning trees ● Big merges leads to missing features
- 19. Deployed === Delivered=== €€€
- 20.
- 21. Business can providequick and effective feedback
- 22. Where to start? Thepractice.
- 23. Everything begins with a ticket “Weneed to have ‘premium users’ and ‘free users’ which will have portal usage limits. Premium users also will get premium features*, for which users are going to pay by credit card**” ...
- 24. Split tasks intosmall chunks
- 25. Splitting payments ● Credit cardprocessing ● Recurring payments ● Invoices ● ...
- 26. Splitting credit card processing byfunction ● Credit card processor integration ● Credit card processing ○ On successful payment ○ On 3D-secure request ■ On success ■ On failure ○ On unsuccessful payment ■ Not enough funds ■ Invalid CC ● UI (credit card form)
- 27. Splitting credit card processing byabstraction ● Frontend ○ HTML ○ JS ● Backend ○ Data validation ○ Processing ■ Pre … ■ Post ... ○ Persistence ● 3rd party integration ○ Library ○ Bridge
- 28. It forces youto think before writing the code
- 29. Small tasks - clearintentions
- 30. Everybody knows whatthey are doing ● Coding ● Reviewing ● Testing ● Deploying
- 31. It’s easier tofocus on small goals
- 32. Focus == Quality ●Do not overthink ● Do not overengineer ● Do only what you need to do * * always improve the codebase
- 33. How small itshould be? One developer - one deployable feature per day.
- 34. It’s the wayto write testable code
- 35. Allows quality codereviews
- 36.
- 37. Reliable and predictablereleases
- 38.
- 39.
- 40. TDD + Functionaltests
- 41.
- 42.
- 43.
- 44.