New branch strategy

Currently, we are using github flow branch strategy (see github flow strategy ), where all the features are merged into master branch. According to some articles, this flow is perfect when we need to continous delivery web apps (or other projects where is not necessary to have multiple version living at the same time) But one of the concerns is, if you merged some untested code into master this code can lead to some issues or errors to the end users

A good way to avoid this is to base our branch strategy from GitFlow branch strategy (see Giflow branch strategy) In this strategy, exists 2 long-living branches (master and develop), where all the feature branches (or ticket branches in our case) came from develop (we will not merge nothing into master except develop branch) This will help us to avoid merge issues into production code (master branch)

With this strategy, we can use some tools like git-flow (installation link here), this tool help us to make the release a bit easier (you can compare the commands of git-flow against normal git sentences here)

Testing

Another important proposed change is to run the acceptance tests for develop branch during the night (right now, the testing suite last over 5 hours to finish). We can use an scheduled event in the workflow definition of the project to run this tests. Also we can add an slack integration to notify when the tests finished into slack channel with a automated message using the same github action (see github slack action)