Branching Your Way to Low-Code Perfection
Download as PPTX, PDF1 like461 views
The document discusses the implementation of a branching capability in low-code development environments to enhance collaboration among developers. It aims to facilitate concurrent work on the same code, improving deployment speed and integration processes. Key features include isolated runtimes for each developer and an improved merge experience, although there are limitations compared to traditional coding environments.
Branching Your Way to Low-Code Perfection
- 1. | Branching your way to low-code perfection Branching your way to low-code perfection Helping development teams collaborate more effectively
- 2. | Branching your way to low-code perfection| Branching your way to low-code perfection James DeVries Senior Solution Architect | OutSystems @ in [email protected] https://www.linkedin.com/in/falebarros/
- 3. | Branching your way to low-code perfection Problem Branching ● As application teams grow, delivery slows down because multiple developers compete to change the same code ● Developers need to deliver at different paces and release teams need to control what is delivered
- 4. | Branching your way to low-code perfection Goal Branching ● Enable collaborative development on OutSystems ● Deliver a new branching capability to allow developers to work concurrently on the same code ● Provide an isolated runtime for continuous integration to deliver at a faster pace
- 5. | Branching your way to low-code perfection Isolated Runtime (branch) Architecture Overview Public Runtime (trunk) Developer DeveloperJunior Dev Public Runtime
- 6. | Branching your way to low-code perfection Hey <developer>, Code this feature...
- 7. | Branching your way to low-code perfection Hey <developer>, Code this feature... How can I work isolated?
- 8. | Branching your way to low-code perfection
- 9. | Branching your way to low-code perfection
- 10. | Branching your way to low-code perfection
- 11. | Branching your way to low-code perfection
- 12. | Branching your way to low-code perfection
- 13. | Branching your way to low-code perfection
- 14. | Branching your way to low-code perfection
- 15. | Branching your way to low-code perfection
- 16. | Branching your way to low-code perfection Hey Tech Lead, Help the (junior) developer... JUNIOR DEVELOPER I’ll just show how to fix the code!
- 17. | Branching your way to low-code perfection
- 18. | Branching your way to low-code perfection
- 19. | Branching your way to low-code perfection
- 20. | Branching your way to low-code perfection Hey <team>, Put your stuff into Production...
- 21. | Branching your way to low-code perfection Hey <team>, Put your stuff into Production... We have to wait for others..
- 22. | Branching your way to low-code perfection
- 23. | Branching your way to low-code perfection
- 24. | Branching your way to low-code perfection
- 25. | Branching your way to low-code perfection
- 26. | Branching your way to low-code perfection
- 27. | Branching your way to low-code perfection
- 28. | Branching your way to low-code perfection
- 29. | Branching your way to low-code perfection Hey IT, When will feature X be available? How can I deploy only some features?
- 30. | Branching your way to low-code perfection
- 31. | Branching your way to low-code perfection
- 32. | Branching your way to low-code perfection
- 33. | Branching your way to low-code perfection
- 34. | Branching your way to low-code perfection
- 35. | Branching your way to low-code perfection
- 36. | Branching your way to low-code perfection
- 37. | Branching your way to low-code perfection
- 38. | Branching your way to low-code perfection
- 39. | Branching your way to low-code perfection Hey IT, There’s a bug in production...
- 40. | Branching your way to low-code perfection Hey IT, There’s a bug in production... How can I just deploy the bug fix?
- 41. | Branching your way to low-code perfection
- 42. | Branching your way to low-code perfection
- 43. | Branching your way to low-code perfection
- 44. | Branching your way to low-code perfection
- 45. | Branching your way to low-code perfection
- 46. | Branching your way to low-code perfection
- 47. | Branching your way to low-code perfection
- 48. | Branching your way to low-code perfection
- 49. | Branching your way to low-code perfection Differences to High Code ● One isolated runtime is granted for each developer. ● Not possible to create new runtimes. ● LifeTime only stages code that is in trunk, meaning, not possible to stage code that is isolated runtimes. ● Isolated runtimes share the database with the environment; there is no isolation of data. ● Each isolated runtime consumes extra memory on Development Environment.
- 50. | Branching your way to low-code perfection ● Support Reactive Web and Mobile runtime ● Improved Merge experience ● “Pull-request”
- 51. | Branching your way to low-code perfection Thank You!
Editor's Notes
- #3: [2 min] Introduce yourself
- #7: Developer isolation use case
- #9: Demo bugfix use case
- #10: In application list, there’s the SHARED AREA
- #11: When opening a module, it is focused on PUBLIC AREA
- #12: Developer does the fix
- #13: Developer may validate the fix in his “Developer Area”
- #15: The URL of the branch version is different (adds username after application name; her OrderManagement/anb/Dashboard.aspx)
- #16: Since it’s fixed, the developer publishes to PUBLIC AREA, which issues a warning that it’s going to MERGE with TRUNK
- #17: Developer isolation use case
- #18: The Tech Lead, opens Service Studio and connects to junior developer’s area
- #19: The Tech Lead opens module from junior developer’s area
- #20: And so, if doing 1CP, module will be updated in junior developer’s area
- #21: Multiple teams at different paces use case
- #23: Demo new feature use case
- #24: The developer may open a module and do significant changes
- #25: Developer is adding a screen
- #26: The developer will validate changes BEFORE sharing with everybody else
- #27: After publishing in SHARED AREA, developer may actually run it
- #28: The URL is different from the Public Area because it includes the developers username
- #29: The new functionality is accessible from outside, meaning it may be validated before merged into trunk
- #30: Cherry-pick release use case
- #31: Demo code review use case
- #32: Release Manager validates functionality; then he opens Service Studio
- #33: The Release Manger connects to junior developer’s area
- #34: The Release Manager opens module from junior developer’s area
- #35: The Release Manager may validate changes, by doing a “Compare and Merge” the module opened from developer’s area and the Public Area
- #36: The Release Manager may check the code
- #37: The Release Manager may then MERGE changes into TRUNK
- #39: The feature becomes available in the trunk
- #40: Fix production code use case
- #42: Demo hotfix use case
- #43: The senior developer connects to pre-prod environment
- #44: There is no feature branching here!
- #45: After fixing the code, the senior developer publishes to Pre-Prod environment
- #46: LifeTime signals a hotfix in Pre-Prod environment
- #47: The senior developer deploys to production
- #48: The senior developer merges changes in development environment
- #49: In the end, all environments are synched
- #51: During next year...