Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Continuous delivery

12 views

Published on

Continuous delivery practice and benefits in PHP.

Published in: Engineering
  • Be the first to comment

  • Be the first to like this

Continuous delivery

  1. 1. Continuous Delivery praktika ir nauda 2017-11-09 VilniusPHP 0x3C Žilvinas Kuusas
  2. 2. Žilvinas Kuusas lead developer Estina / ISIGN.io Twitter: @kuusas Email: zilvinas@kuusas.lt
  3. 3. 2nd of december, 2017
  4. 4. Continuous delivery Release valuable and reliable software FAST
  5. 5. Speed === €€€ * * € - the unit to measure the business value
  6. 6. 10 mins Client Giving some requirements Developer Writing some lines of code FTP Deployment process * * triggered “on file save” PROD It’s DONE! Fast delivery
  7. 7. What can possibly go wrong? ¯_(ツ)_/¯
  8. 8. The bigger your project grows - more problems you get ● ISIGN ○ 3 products ○ X shared components ● Needs ○ Deploy any time, any version Where it all began?
  9. 9. Managing risks ● Identify the main project risks ○ Buggy deployments ■ Availability ○ Software quality ● Risk mitigation ○ Automated tests ○ Deployment process ■ Deploy to staging ■ Schema migrations ■ Rollbacks
  10. 10. Business Says “I NEED STUFF” 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. 11. Is it “done” or is it “done done”?
  12. 12. Everybody should be responsible for delivered result
  13. 13. It is done only when it is DEPLOYED
  14. 14. Identifying issues ● Developer’s DONE 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. 15. Developer deploys using automated scripts! Team effort - 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. 16. Integrating team members into the process ● Communication ● Responsibility boundaries ● Everybody has to know what he is doing
  17. 17. Orchestrating the delivery process ● Atomic tasks ● Atomic commits ● Easy to read ● Easy to review ● Easy to test ● Deployable to prod
  18. 18. Don’t postpone, merge it! ● Avoid long living branches ● Avoid versioning trees ● Big merges leads to missing features
  19. 19. Deployed === Delivered === €€€
  20. 20. Developer’s satisfaction level
  21. 21. Business can provide quick and effective feedback
  22. 22. Where to start? The practice.
  23. 23. Everything begins with a ticket “We need 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. 24. Split tasks into small chunks
  25. 25. Splitting payments ● Credit card processing ● Recurring payments ● Invoices ● ...
  26. 26. Splitting credit card processing by function ● 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. 27. Splitting credit card processing by abstraction ● Frontend ○ HTML ○ JS ● Backend ○ Data validation ○ Processing ■ Pre … ■ Post ... ○ Persistence ● 3rd party integration ○ Library ○ Bridge
  28. 28. It forces you to think before writing the code
  29. 29. Small tasks - clear intentions
  30. 30. Everybody knows what they are doing ● Coding ● Reviewing ● Testing ● Deploying
  31. 31. It’s easier to focus on small goals
  32. 32. Focus == Quality ● Do not overthink ● Do not overengineer ● Do only what you need to do * * always improve the codebase
  33. 33. How small it should be? One developer - one deployable feature per day.
  34. 34. It’s the way to write testable code
  35. 35. Allows quality code reviews
  36. 36. Distribute workload
  37. 37. Reliable and predictable releases
  38. 38. The final touch
  39. 39. Automation over documentation
  40. 40. TDD + Functional tests
  41. 41. Monitoring & Alerting
  42. 42. Build better products!
  43. 43. FASTER
  44. 44. QUESTIONS?

×