0

We are using SVN as our version control system and we are using the below standard layout for our projects.

Tags
Branches
Trunk

Trunk: -> Trunk will always hold the latest code changes.

Branches: -> When a release is planned a new branch will be created from the trunk and worked upon. Once the same is released it will be tagged.

Tags: -> Now after the release if we notice any issues in the delivered application then we create a new branch from the tags and then it is worked upon. Finally, the changes made will be merged into the trunk. Or sometimes we make the fix on trunk first and then backport it.

Is this the standard approach? or is there any recommended best practice?

Vivek
  • 5
  • 1
  • 5

1 Answers1

0

We use Git for our VCS. We follow Trunk based development strategy. Trunk-Based Development (TBD) is where all developers (for a particular deployable unit) commit to one shared branch under source-control. That branch is going to be colloquially known as trunk, perhaps even named “trunk”. lie of omission

This trunk is always stable, but it can have unfinished features covered by feature toggles. This type of development works

  • When you are just starting up
  • When you are iterating quickly

In short, feature branches will give you better isolation, but require you to deal with the pain of deferred integration, and merges. Toggles give you continuous integration, but require you to design/implement your code in such a way that supports toggles, and introduce the risk that unfinished feature code could negatively affect production.

Sunil
  • 184
  • 1
  • 4