GeneXus Android team - Development Process

Shows the development process that we use on GeneXus Android team

Transcript

1. DEVELOPMENT PROCESS GENEXUS ANDROID TEAM JUAN ANDRÉS DIANA
2. CONTENT ▸ Repositories structure ▸ Tools ▸ Development workflow ▸ Additional tools ▸ Release workflow ▸ Impact of these changes
3. Repositories structure
4. REPOSITORIES STRUCTURE MAIN REPOSITORIES
5. REPOSITORIES STRUCTURE MAIN REPOSITORIES ▸ Genexus. Uses SVN. Hosted on a internal network server
6. REPOSITORIES STRUCTURE MAIN REPOSITORIES ▸ Genexus. Uses SVN. Hosted on a internal network server ▸ Android’s FlexibleClient. Uses Git. Hosted on GitHub
7. REPOSITORIES STRUCTURE MAIN REPOSITORIES ▸ Genexus. Uses SVN. Hosted on a internal network server ▸ Android’s FlexibleClient. Uses Git. Hosted on GitHub ▸ GeneXus Standard Classes. Uses Git. Hosted on GitHub (Currently migrating)
8. REPOSITORIES STRUCTURE GENEXUS TRUNK STABLE
9. REPOSITORIES STRUCTURE GENEXUS TRUNK STABLE Tested! Tested!
10. REPOSITORIES STRUCTURE ANDROID FLEXIBLE CLIENT master
11. REPOSITORIES STRUCTURE ANDROID FLEXIBLE CLIENT my-issue1-branch master
12. REPOSITORIES STRUCTURE ANDROID FLEXIBLE CLIENT my-issue1-branch master
13. REPOSITORIES STRUCTURE ANDROID FLEXIBLE CLIENT my-issue1-branch master
14. REPOSITORIES STRUCTURE ANDROID FLEXIBLE CLIENT my-issue1-branch master my-issue2-branch
15. REPOSITORIES STRUCTURE ANDROID FLEXIBLE CLIENT master my-issue2-branch
16. REPOSITORIES STRUCTURE ANDROID FLEXIBLE CLIENT master
17. REPOSITORIES STRUCTURE ANDROID FLEXIBLE CLIENT master beta
18. REPOSITORIES STRUCTURE ANDROID FLEXIBLE CLIENT my-issue1-branch master beta
19. REPOSITORIES STRUCTURE ANDROID FLEXIBLE CLIENT my-issue1-branch master beta
20. Tools
21. MAN IS A TOOL-USING ANIMAL; WITHOUT TOOLS HE IS NOTHING, WITH TOOLS HE IS ALL. Thomas Carlyle
23. Code Review s
29. ?
30. TOOLS ARCHITECTURE OVERVIEW
31. TOOLS ARCHITECTURE OVERVIEW
32. TOOLS ARCHITECTURE OVERVIEW
33. TOOLS ARCHITECTURE OVERVIEW
34. TOOLS ARCHITECTURE OVERVIEW GENEXUS BUILD
35. TOOLS ARCHITECTURE OVERVIEW GENEXUS BUILD
36. Development workflow
37. DEVELOPMENT WORKFLOW #1. DECIDE AN ISSUE TO WORK ON
38. DEVELOPMENT WORKFLOW #2. OPEN A BRANCH FROM MASTER TO START WORKING
39. DEVELOPMENT WORKFLOW #2. OPEN A BRANCH FROM MASTER TO START WORKING
40. DEVELOPMENT WORKFLOW #2. OPEN A BRANCH FROM MASTER TO START WORKING Why work on a separate branch for each change?
41. DEVELOPMENT WORKFLOW #2. OPEN A BRANCH FROM MASTER TO START WORKING Why work on a separate branch for each change? ▸ Ease of working on several change sets in parallel
42. DEVELOPMENT WORKFLOW #2. OPEN A BRANCH FROM MASTER TO START WORKING Why work on a separate branch for each change? ▸ Ease of working on several change sets in parallel ▸ Avoid change sets hell
43. DEVELOPMENT WORKFLOW #2. OPEN A BRANCH FROM MASTER TO START WORKING Why work on a separate branch for each change? ▸ Ease of working on several change sets in parallel ▸ Avoid change sets hell ▸ Higher code quality before merging to master
44. DEVELOPMENT WORKFLOW #2. OPEN A BRANCH FROM MASTER TO START WORKING Why work on a separate branch for each change? ▸ Ease of working on several change sets in parallel ▸ Avoid change sets hell ▸ Higher code quality before merging to master ▸ Higher confidence on our tests (as they were performed in isolation)
45. DEVELOPMENT WORKFLOW #2. OPEN A BRANCH FROM MASTER TO START WORKING How do I create a new branch from master? ▸ From command-line:
 git checkout -b my-new-feature ▸ From the IDE or GUI Tool:
46. DEVELOPMENT WORKFLOW #2. OPEN A BRANCH FROM MASTER TO START WORKING How do I create a new branch from master? ▸ From command-line:
 git checkout -b my-new-feature ▸ From the IDE or GUI Tool:
47. DEVELOPMENT WORKFLOW #3. WORK ON THE BRANCH UNTIL IT’S READY FOR REVIEW
48. DEVELOPMENT WORKFLOW #3. WORK ON THE BRANCH UNTIL IT’S READY FOR REVIEW Best Practices
49. DEVELOPMENT WORKFLOW #3. WORK ON THE BRANCH UNTIL IT’S READY FOR REVIEW Best Practices ▸ Many commits!
50. DEVELOPMENT WORKFLOW #3. WORK ON THE BRANCH UNTIL IT’S READY FOR REVIEW Best Practices ▸ Many commits! ▸ Rewriting the history, fear not!
51. DEVELOPMENT WORKFLOW #3. WORK ON THE BRANCH UNTIL IT’S READY FOR REVIEW Best Practices ▸ Many commits! ▸ Rewriting the history, fear not! Easier Code Reviews!
52. DEVELOPMENT WORKFLOW #4. OPEN A PULL REQUEST ON GITHUB ▸ Push the branch to GitHub ▸ Open the Pull Request ▸ Write a good description
53. DEVELOPMENT WORKFLOW #4. OPEN A PULL REQUEST ON GITHUB
54. DEVELOPMENT WORKFLOW #4. OPEN A PULL REQUEST ON GITHUB
55. DEVELOPMENT WORKFLOW #4. OPEN A PULL REQUEST ON GITHUB
56. DEVELOPMENT WORKFLOW #4. OPEN A PULL REQUEST ON GITHUB
57. DEVELOPMENT WORKFLOW #5. KEEP WORKING ON THE PULL REQUEST UNTIL IT’S READY TO BE MERGED When is a PR ready to be merged?
58. DEVELOPMENT WORKFLOW #5. KEEP WORKING ON THE PULL REQUEST UNTIL IT’S READY TO BE MERGED When is a PR ready to be merged? 1. TeamCity must report a successful build
59. DEVELOPMENT WORKFLOW #5. KEEP WORKING ON THE PULL REQUEST UNTIL IT’S READY TO BE MERGED When is a PR ready to be merged? 1. TeamCity must report a successful build 1. Build 2. Unit Tests 3. Static code analyzers (Error-prone, Android Lint, Checkstyle) 4. Publish to Nexus
60. DEVELOPMENT WORKFLOW #5. KEEP WORKING ON THE PULL REQUEST UNTIL IT’S READY TO BE MERGED When is a PR ready to be merged? 1. TeamCity must report a successful build 2. Approved by at least one teammate
61. DEVELOPMENT WORKFLOW #5. KEEP WORKING ON THE PULL REQUEST UNTIL IT’S READY TO BE MERGED When is a PR ready to be merged? 1. TeamCity must report a successful build 2. Approved by at least one teammate 3. Tested by the support team
62. DEVELOPMENT WORKFLOW #5. KEEP WORKING ON THE PULL REQUEST UNTIL IT’S READY TO BE MERGED When is a PR ready to be merged? 1. TeamCity must report a successful build 2. Approved by at least one teammate 3. Tested by the support team
63. DEVELOPMENT WORKFLOW #5. KEEP WORKING ON THE PULL REQUEST UNTIL IT’S READY TO BE MERGED When is a PR ready to be merged? 1. TeamCity must report a successful build 2. Approved by at least one teammate 3. Tested by the support team
64. DEVELOPMENT WORKFLOW #6. MERGE THE BRANCH TO MASTER #1 #2 #3 #4
65. DEVELOPMENT WORKFLOW #6. MERGE THE BRANCH TO MASTER
66. DEVELOPMENT WORKFLOW #6. MERGE THE BRANCH TO MASTER
67. DEVELOPMENT WORKFLOW #7. CODE IS NOW READY TO BE SHIPPED ON THE NEXT UPGRADE
68. Additional Tools
69. ADDITIONAL TOOLS AUTO-MERGE BOT my-issue1-branch master beta
70. ADDITIONAL TOOLS AUTO-MERGE BOT my-issue1-branch master beta bot
71. ADDITIONAL TOOLS AUTO-MERGE BOT
72. ADDITIONAL TOOLS AUTO-MERGE BOT
74. ADDITIONAL TOOLS MERGEABLE BOT my-issue1-branch master my-issue2-branch
75. ADDITIONAL TOOLS MERGEABLE BOT master my-issue2-branch
76. ADDITIONAL TOOLS DELETE MERGED BRANCH BOT
77. ADDITIONAL TOOLS MERGEABLE BOT
78. ADDITIONAL TOOLS MERGEABLE BOT
79. ADDITIONAL TOOLS MERGEABLE BOT
80. ADDITIONAL TOOLS MERGEABLE BOT
81. Release workflow
82. RELEASE WORKFLOW STEPS ▸ Create a new release branch master release-16.3
83. RELEASE WORKFLOW STEPS ▸ Cherry pick changes that must go in 16.3 master release-16.3
84. RELEASE WORKFLOW STEPS ▸ Tag the release master release-16.3 Tag: 16.3
85. RELEASE WORKFLOW STEPS ▸ Publish the release version in Nexus and the CHANGELOG in GitHub
86. Impact of these changes
87. IMPACT OF THESE CHANGES BENEFITS ✓ Higher code quality ✓ Code reviews ✓ Change sets tested in isolation
88. IMPACT OF THESE CHANGES BENEFITS ✓ Higher code quality ✓ Code reviews ✓ Change sets tested in isolation ✓ SCM is much faster and stable
89. IMPACT OF THESE CHANGES BENEFITS ✓ Huge improvement in build feedback ✓ Android FlexibleClient build avg. time: < 2 min (down from hours) ✓ Signal to noise ratio is awesome (no more build emails)
90. IMPACT OF THESE CHANGES BENEFITS ✓ Huge improvement in build feedback ✓ Android FlexibleClient build avg. time: < 2 min (down from hours) ✓ Signal to noise ratio is awesome (no more build emails) ✓ CI is easily scalable, updatable and has much better integrations ✓ Built on top of Docker
91. IMPACT OF THESE CHANGES BENEFITS ✓ Agile test process ✓ Less than 25 mins from Fixed to Tested! (before it took hours literally)
92. IMPACT OF THESE CHANGES BENEFITS ✓ Agile test process ✓ Less than 25 mins from Fixed to Tested! (before it took hours literally) ✓ Much better tracking of the changes ✓ PRs list brings gap visibility (no more lost issues into oblivion) ✓ CHANGELOG let us see what changed in each release
93. Q & A