Continuous delivery practice and benefits in PHP.

1. Continuous Delivery
praktika ir nauda
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
and reliable software
FAST

5. Speed === €€€ *
* € - the unit to measure the business value

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. What can possibly go wrong?
¯_(ツ)_/¯

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. 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. 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. Is it “done” or is it “done done”?

12. Everybody should be responsible
for delivered result

13. It is done only when it is
DEPLOYED

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. 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. Integrating team members into the process
● Communication
● Responsibility boundaries
● Everybody has to know what he is doing

17. Orchestrating the delivery process
● Atomic tasks
● Atomic commits
● Easy to read
● Easy to review
● Easy to test
● Deployable to prod

18. Don’t postpone, merge it!
● Avoid long living branches
● Avoid versioning trees
● Big merges leads to
missing features

19. Deployed === Delivered === €€€

20. Developer’s
satisfaction level

21. Business can provide quick and
effective feedback

22. Where to start?
The practice.

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. Split tasks into small chunks

25. Splitting
payments
● Credit card processing
● Recurring payments
● Invoices
● ...

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. Splitting credit
card processing
by abstraction
● Frontend
○ HTML
○ JS
● Backend
○ Data validation
○ Processing
■ Pre …
■ Post ...
○ Persistence
● 3rd party integration
○ Library
○ Bridge

28. It forces you to think
before writing the code

29. Small tasks -
clear intentions

30. Everybody knows what they are doing
● Coding
● Reviewing
● Testing
● Deploying

31. It’s easier to focus
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 it should be?
One developer - one deployable feature per day.

34. It’s the way to write testable code

35. Allows quality code reviews

36. Distribute workload

37. Reliable and predictable releases

38. The final touch

39. Automation over documentation

40. TDD + Functional tests

41. Monitoring & Alerting

42. Build better products!

43. FASTER

44. QUESTIONS?