The successful codeline process

Introduction

A friend of mine asked me on one of the meetup, how frequently we are releasing the features on production. I said 3 week once. ie. every end of sprint

He was surprised and asked me how many people working on the product, I said it was 14, all the 14 will code

Then my friend surprisingly asked how are we managing code conflicts as many developer working on same codeline with different multiple features , bugfix

oh Yeah... In this blog post I will share you the most successful codeline strategy we using for past 4 years.

This will be useful for people managing multiple repositories , And also for new product development .

Git Codeline process

a picture is worth a thousand words

develop holds all completed feature branches and reflects the latest development code. Continuous builds run on this branch.

main - only stable code is merged from the develop branch. Nightly / Publish builds run on this branch.

release/* branches - branched out of the main branch, for every release. Tagged for each release.

Pull Request denied, if PR-Merge-build fails

• feature/* branches - branched out of the develop branch. usually short-living - when a feature is ready it is merged back to develop and the branch is closed.

• 

manual pull should be fetched/refreshed to consecutive feature branch

Will run on develop branch, so that each developer commit is responsible for success/failure

Pull Request Merge build will certify before integrate into main or release branch. This process involves merging the source branch i.e. develop or hotfix branch, into the target branch i.e main or release branch, with out committing into main

E2E test will runs on main branch. Any failure should be treat as blocker.

E2E test will runs on release branch. Any failure should be treat as blocker.

Advantages

• Developer will always work on successful builds
• No conflicts.
• Merge will be reviewed by peers
• Saves more time