The Art of Migration and Versioning

Transcript

1. It Can Break The App! The art of Migration and Versioning Muhammad Mufid Afif https://mufid.github.io July 15th, 2017 LightningTalk @ GeekCamp ID 2017 SCTV Tower
2. $ whoami Me Work
3. $ whoami Community Member
4. $ whoami Latest Product
9. v1 v2
12. Migration!
13. Mostly, Database Change from one form to another form
14. Versioning!
15. Mostly, API Allow multiple version work with the same thing
16. 0% Akal-akalan 100% Science See CMMI!
17. Why we need migration and versioning? Version 1 Version 2 Table: Books Title: String BookType: Integer Table: Books Title: String BookType: String
18. Why we need migration and versioning? Version 1 Version 2 Table: Books Title: String BookType: Integer Table: Books Title: String BookType: String Not backward compatible Not forward compatible
19. Why we need migration and versioning? Version 1 Version 2 Table: Books Title: String BookType: Integer Table: Books Title: String BookType: Integer BookTypeName: String Better!
20. Migrating DB • Always make sure have backup! • Check: is it blocking operation? Is downtime allowed? • Check: have you run old version with new db, and new version with old db? • Everything checked? Deploy!
21. DB Migration: Does it requires downtime? Operation Blocking operation? Add column without DEFAULT No Add column with DEFAULT Yes Create new table No Add new index use CONCURRENTLY
22. It is always safe to add thing But please do deletion and data changing in different version!
24. Let's talk about more fundamental thing!
25. High Availability
26. High Availability Online Migration Multiple Tenancy Graceful Degradation Gradual Rollout API Versioning
27. Depends to your business
28. Game: Maintenance Period & version matching Some games doesn't allow multiple versions running and doesn't keep at 100% availability
30. People tried to make versioning better, but the essential is the same
31. Protocol, Compared Protocol Definition File Definition File is Remotely Acessible? SOAP Yes Yes JSON/REST via Swagger or whatever via Docs GraphQL Yes via Docs GRPC / Protobuf Yes via proto File
32. Perhaps, definition can be accessed by client is a good thing. They can check whether they're using actual version, or they must upgrade theirself before calling APIs.
33. Protocol, Compared Protocol Protocol Base Protocol Syntax SOAP HTTP XML JSON/REST HTTP JSON GraphQL HTTP GraphQL GRPC / Protobuf Strictly H2 Protobuf
34. Can we have a versioning in field-level?
35. But still, all of them failed to address our problem! Protocol Allow field change? SOAP No JSON/REST No GraphQL No GRPC / Protobuf No
36. "It is always safe adding more fields." Well....
37. Versioning API • Soft deprecate old method / field: announce warnings • Hard deprecate old method / field: throw error • Delete the method / field
38. Our previous consensus still relevant, then.
39. Conclusion • Target your audience. Who will use your app? Is it mission-critical things? • Target the change. Should previous data preserved? • Target the availability. Is 100% availability is a must? • At any changes, either in migration or versioning, it is always safe to add things, but be careful when changing / deleting things.
40. Thank you!
41. Credits • icon: Freepik via Flaticon • icon: Madebyoliver via Flaticon