Change Management

Branching model

• there are 3 important kind of branches
• master always contains the latest stable and generally accepted state in the form of specific merge commits from the dev branch
• the dev branch contains the latest development changes, that are verified to work by unit tests and 2 reviewers (see Commit-Policy)
• specific feature branches, created by the developers

Acceptance criteria for dev branch

dev contains the latest changes that are considered to be working by their creators and at least 2 reviewers. To continually ensure good quality of code some requirements must be met for a commit to be allowed into dev:

• all commits belong to a github Issue
• the Issue contains an understandable description of the problem that enables reproduction
• the Issue contains an understandable and assessable description of the solution
• all code changes are well documented, formatted according to (not yet publicly available) coding standards and high quality in other standards that might be formalized later on
• unit tests with 100% statement coverage for the code changes
• if necessary and possible: adapted documentation and integration tests
• 2 DFE team members acknowledge the issue's success

These requirements can be overruled only by 100% acceptance of all developers, reviewers and both maintainers for a single Issue.

All changes to these rules must be accepted in a Stammtisch Meeting.

Development Process

This is a suggestion, but following these suggestions is considered to be most effective by the maintainers to get your changes into the dev branch.

• Create the issue in the Github tracker
• Discuss the problem (-description) with the mailing list, Stammtisch or other developers to make sure, it's well enough described and understood.
• Also discuss solution suggestions and their implications.
• Document the chosen solution within the Issue and explain why this solution was chosen.
• Create a feature branch (or fork, if you don't have commit rights on the DFE repository) for your Issue and don't forget to name your Issue number (e.g. #123) in your commit thereby ensuring it can be referenced accordingly. Develop and discuss with other developers according to the situation. For bigger changes consider breaking them down into smaller steps, which increases the chance of your changes to be applied to the dev branch.
• Write unit tests for your code changes, preferably while writing the actual code.
• Find 2 team members to acknowledge your success. The smart developer will look for these guys early on in the development process and keep them interested in the topic.
• When all requirements appear to be fulfilled, inform the maintainer (an @name in a comment might be sufficient).
• After applying any changes that may be requested by the maintainer, you might still have to make sure, that he really commits your changes to the dev branch.

Acceptance criteria for master branch

dev branch may be merged into master whenever the Stammtisch decides its current state warrants doing so.