Branches

From the very beginning we organized our repositories to match the code flow. We use two main branches (master and development) and a few other for features, fixes and bugs. We use the master branch as reflection of production code, and development for staging purposes. For every new feature and bug fix we create a new branch, connect it to a backlog item and monitor the progress at all times. We use naming which allows us to easily distinguish between branches and their purposes. We also tag important milestones to match their releases.

Development

While we use different IDE and text editors we strongly standarized coding. Following internal rules of casing, formatting, code reusing, code structure, architecture, files organization allows us create uniform sources for every project. We use mainly two different aproches for development depending on needs - FDD (feature driven development) or TDD (test driven development). We also aim at strong design patterns. At the end of the day code is refactored & linted for streamline and optimized shape matching our strong standards and all needs of solution.

Visual Studio

VS Code

Visual Studio for mac

JetBrains Rider

Vim

Notepad

Pull requests & code review

Every line of code that we want to add to development and master branch is checked twice. We use cross-review of developers. We look for all kinds of problems in code - from architecture, through structure, bad patterns and naming convention to formatting or casting mistakes. This method allows us to catch potential dangers on the development level and optimize code therefore making it safer before we even get to the testing stage. Sometimes we need to rethink an idea, revert changes and abandon a pull request. It happens, but it’s better to take a minute and review rather than have issues on production.

Multilevel verification

Cross-review

No unresolved comments

Minimum of two reviewers

Tests

The last - but by no means least important - step is testing. During the development process all of our code needs to pass through unit and integration tests. Only then, after merging to development, we test it using automated scenarios and using manual tests. If everything goes fluently we are ready to merge the code into the production branch and create a second pull request resulting in code review and unit and integration tests from many feature branches.

Unit

Manual

Integration

Automated

Code flow