8. Source Control
With a source control system:
• Changes to the artifacts are preserved
• Changes can be done in isolation
• Changes are eventually integrated
8
BEXIS Tech Talk #7: Configuration and
Change Management
9. Source Control
• Isolation
– Bug fixes
– Releases
– New Features
– Developer work
9
BEXIS Tech Talk #7: Configuration and
Change Management
10. Source Control
• Integration
– Merging isolated work
– Propagating fixes and features
– Promoting quality
10
BEXIS Tech Talk #7: Configuration and
Change Management
11. Source Control
• Use commits for change preservation
• Use branches for isolation
• Use merging for integration
11
BEXIS Tech Talk #7: Configuration and
Change Management
12. Branching Approach
• Branch for Team Members
• Branch for Features
• Branch for Architectural elements
• Branch for Releases
• Branch for Safekeeping
• Ad-hoc Branching
– Risky features
– Complex bugs during releases
– Temporary work: refactoring, framework upgrades
12
BEXIS Tech Talk #7: Configuration and
Change Management
13. Branches
13
BEXIS Tech Talk #7: Configuration and Change
Management
Master
DEV
Modules/DCM Modules/RPM
Components/DLM Components/EXT
14. The Master Branch
• Is used for safe keeping
• No coding, no changes
• All test cases pass!
14
BEXIS Tech Talk #7: Configuration and
Change Management
15. The DEV Branch
• Integration Branch
• Always for the next release
• No coding here
• Code always compiles!
• Integration tests pass!
• Occasional changes for conflict resolution:
– Configuration
– Merge
15
BEXIS Tech Talk #7: Configuration and
Change Management
16. The Module Branches
• Adding new features to next releases
• Unit tests pass!
• Branch name: modules/<moduleID>
• Forked from the DEV branch
• Get merged from DEV first
• Merge into DEV
• May be locked during releases
16
BEXIS Tech Talk #7: Configuration and
Change Management
17. The Component Branches
• Adding new features to next releases
• Unit tests pass!
• Branch name: components/<componentID>
• Forked from the DEV branch
• Get merged from DEV first
• Merge into DEV
• May be locked during releases
17
BEXIS Tech Talk #7: Configuration and
Change Management
19. Policies & Practices
• Branches can be used by more than one
developer
• Developers may work on more than one
branch
• Branches may have ad-hoc/temporary sub-
branches
19
BEXIS Tech Talk #7: Configuration and
Change Management
20. Policies & Practices
• Work in isolation
• Get upper changes ASAP
• Pull before Push
• Fix issues on deepest (or isolated) branch
• Maintain target branch’s quality after merging
20
BEXIS Tech Talk #7: Configuration and
Change Management
21. Releases
• To publish a coherent set of working artifacts
– A set of chosen features
– From the release backlog
– Every 3-4 months
21
BEXIS Tech Talk #7: Configuration and
Change Management
22. Release Materials
• Binary code
• Source code
• Documentation
• Sample Demo Site
• Initial Data/Workspace
• DB Scripts
22
BEXIS Tech Talk #7: Configuration and
Change Management
23. Builds under Control, too!
• Bundling Scripts
– Compilation
– DB change scripts
– Document/Manual Formatting (PDF, HTML)
– Branding Information
– Commands
– Packaging
23
BEXIS Tech Talk #7: Configuration and
Change Management
24. Branching for Release
• Release branch is:
– forked from DEV
• Name: /releases/<x>.<y>
– Used for stabilizing the designated feature set
– Used by all the release team members
– Is built daily
– Is staged daily (for testing)
– Is tagged, bundled, and published
24
BEXIS Tech Talk #7: Configuration and
Change Management
25. Branching for Release
25
BEXIS Tech Talk #7: Configuration and Change
Management
Master
DEV
R1
Released V1.0 Released V1.1
R2
Released V2.1Released V2.0
26. Release Branching
• Is used to isolate other branches, releases,
and the development from the changes.
• Supports multiple alive releases
– Previously released ones
– The current one
• Allows previous releases reproduction
• Permits exact version bug assignment, fixing,
and promotion.
26
BEXIS Tech Talk #7: Configuration and
Change Management
27. Release Integration
• Merge all module and component branches to
DEV
• Create the release branch from DEV
• Do not merge again from DEV during release
– Necessary cases can be handled with care!
– Merge to DEV is safe
27
BEXIS Tech Talk #7: Configuration and Change
Management
28. Release Integration
• Promote the release code
– Realases/<x.y> DEV
– DEV module branches
– DEV component branches
– DEV master
• Tag branches accordingly
28
BEXIS Tech Talk #7: Configuration and
Change Management
29. The Github Repository
• https://github.com/BEXIS2
• Updated after major releases
29
BEXIS Tech Talk #7: Configuration and Change
Management
30. Public Repository
30
BEXIS Tech Talk #7: Configuration and
Change Management
Master
DEV
R1
Released V1.0 Released V1.1
R2
Released V2.1Released V2.0
Github Repo: master
V1.0
V1.1
V2.0
V2.1
31. The Public Repository
• Open Source
• Fork
• Pull Request
• Feature Request
• Bug Reporting
31
BEXIS Tech Talk #7: Configuration and Change
Management
https://github.com/BEXIS2
1: <Mailto: bexis2-dev@listserv.uni-jena.de>
<Subscribe to: https://lserv.uni-jena.de/mailman/listinfo/bexis2-dev>
1
1
32. Contribution Projects
• Use the public repository
• Pull the released versions
• Develop on top of them
• Publish their contribution freely
• Share their enhancements with us
32
BEXIS Tech Talk #7: Configuration and Change
Management
33. Outlook
What‘s next in the talk series?
Implementation Notes
BEXIS Tech Talk #7: Configuration and
Change Management
33
