Code flow


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.

479b9b2 Initial commit - aveneo <> 12349fb Add TypeScript - aveneo <> cc7789e Make it work. - aveneo <> b0f3479 Make it right. - aveneo <> 5bc0361 Make it fast. - aveneo <> features/feature-579_add-typescript 95365bc Merge branch features/feature-579_add-typescript - aveneo <> f6c03da Fix it. - aveneo <> bugs/bug-127_loader e4cae17 Merge branch bugs/bug-127_loader - aveneo <> 09b85ea Prepare v1 - aveneo <> development 8e7fe48 Merge branch development - aveneo <> master v1.0.0



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 Logo
Visual Studio
VS Code Logo
VS Code
Visual Studio for mac Logo
Visual Studio for mac
JetBrains Rider Logo
JetBrains Rider
Vim Logo
Notepad Logo

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
No unresolved comments
Minimum of two reviewers
Pull requests & code review


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.



For each project we create fully automated deployments and continoues integrations (thanks to Azure Pipelines and Azure Artifacts). From 2019 we deploy every single one of our solutions in container model - ready for Docker and Kubernetes.

Are you ready to talk about your project?