7 Source Control and Release Management

BEXIS Tech Talk Series

#7: Configuration and Change Management

Javad ChamanaraOctober 2016Jena, Germany

2BEXIS Tech Talk #7: Configuration and Change Management

Reminder: The CM

DataMetadata

Data StructureMetadata Structure Semantics Geo

Administration Security

«use»

«use»

«use» «use»

«use»


Reminder: The Architecture

DB2 PgS

Data Access

Security

Core Functions

UI

UI Framework

...

Modularity

Integration

Synthesis Work

Semantic Search

Analytics

User Defined

Spatial Querying

External Tools

Web Services

Archiving

Import/ Export

Publishing


The Application’s Elements

• Core• Modules• Contributions• 3rd Party Libraries


Configuration and Change Management

• Change Management• Source Control• Release Management


Change Management

• Agile– Scrum

• MS TFS– Backlogs– Tasks– Change Requests– Sprints

7

Change Management

• Product backlog• Release backlog• Sprint backlog• Work Item assignment

BEXIS Tech Talk #7: Configuration and Change Management


Source Control

With a source control system:• Changes to the artifacts are preserved• Changes can be done in isolation• Changes are eventually integrated


Source Control

• Isolation– Bug fixes– Releases– New Features– Developer work


Source Control

• Integration– Merging isolated work– Propagating fixes and features– Promoting quality


Source Control

• Use commits for change preservation• Use branches for isolation• Use merging for integration


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

13

Branches


Master

DEV

Modules/DCM Modules/RPM

Components/DLM Components/EXT

Components/DLM

_Data


The Master Branch

• Is used for safe keeping• No coding, no changes• All test cases pass!


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


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


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


Tooling

• GIT• TFS VC– GIT integration

• Github• Visual Studio


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


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


Releases

• To publish a coherent set of working artifacts– A set of chosen features– From the release backlog– Every 3-4 months


Release Materials

• Binary code• Source code• Documentation• Sample Demo Site• Initial Data/Workspace• DB Scripts


Builds under Control, too!

• Bundling Scripts– Compilation– DB change scripts– Document/Manual Formatting (PDF, HTML)– Branding Information– Commands– Packaging


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

25

Branching for Release


Master

DEV

R1

Released V1.0 Released V1.1

R2

Released V2.1Released V2.0


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.

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



Release Integration

• Promote the release code– Realases/<x.y> DEV– DEV module branches– DEV component branches– DEV master

• Tag branches accordingly

29

The Github Repository

• https://github.com/BEXIS2• Updated after major releases



Public Repository

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


https://github.com/BEXIS2

1: <Mailto: [email protected]> <Subscribe to: https://lserv.uni-jena.de/mailman/listinfo/bexis2-dev>

1

1

mailto:[email protected]

https://lserv.uni-jena.de/mailman/listinfo/bexis2-dev

https://lserv.uni-jena.de/mailman/listinfo/bexis2-dev

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



Outlook

What‘s next in the talk series?

Implementation Notes


34

Thanks!Questions?

Contact:[email protected]://bexis2.uni-jena.de

Acknowledgment

Software

7 Source Control and Release Management