0

I have a bitbucket project in which many team members are working with. Each team members create separate feature branch for the new feature development and when he is done up he commits the code to the feature branch...upon committing a jenkins job will run for quality testing, further he creates a pull request. The admin user after checking the code will later merge the code to the master for production deployment.

The above process is working fine but would like to know what are other best ways in which we can manage and maintain the repos suitable for production, staging, testing and development environments. I have a idea in my mind which is like creating three sub branches from the main master branch like staging, development, testing. Now the development team will create feature branches from development sub branch and they works and pushes the changes onto it. Later the changes will be merged to development sub branch and deploys in dev environment, further merges to testing sub branch and deploys in test environment, further merges to staging sub branch and deploys in staging environment, after testing merges to main master branch and deploys in production environment.

Can anyone suggest me a best approach better the above for source code management for production, staging, testing and development environments

Alex Man
  • 4,746
  • 17
  • 93
  • 178

1 Answers1

1

The second approach can work, provided that:

  • you reset your staging/dev/testing branches at each new release cycle, making those branches ephemeral (ie destroyes/recreated)
  • you merge the feature branches to those branches (instead of merging from dev to test to staging)

See the git workflow as an example (not "git flow", but the workflow used for the Git repo itself): by merging the feature branches directly to each environment branches, you avoid any dependencies between those branches (staging does not depend on test which does not depend on dev), and it becomes very easy to cancel some of those feature during the integration done in those different environments: all you need to not merge that feature branch in the next environment branch.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • Thanks for the reply. Can you please tell me what is the purpose of making those branches ephemeral after the release. Also I didn't get this point **you merge the feature branches to those branches (instead of merging from dev to test to staging)**. Actually I thought in the way in which developers can create feature branches inly from **development** sub branch – Alex Man Jan 14 '18 at 06:35
  • @AlexMan See https://hackernoon.com/how-the-creators-of-git-do-branches-e6fcc57270fb: if you merge the environment branches themselves, it becomes difficult to cancel feature branches already in dev that you don't want anymore in testing. If you merge directly the feature branches, all you need to do is not merge the one you don't want in the next environment. – VonC Jan 14 '18 at 06:38
  • @AlexMan That means at any time, you can continue developing your feature branch by rebasing it on the current state of dev or test or staging, instead of trying to fix it in those branches. – VonC Jan 14 '18 at 06:42
  • @AlexMan In other words, to test a feature branch in integration with the other ones already selected as candidate for dev/test/or staging, you don't have to merge your own feature branch, you can rebase it on top of dev or test or staging, fix whatever prevented you to integrate to that environment, and then merge it. – VonC Jan 14 '18 at 06:44