What is the best way to organize the development process?

Question

subversion

Good day!

I will outline the situation:
There is a software product, this product is supplied to various subjects of the Russian Federation.
It happens that one of the subjects asks to add (remove) some features that he needs (not needed), but at the same time, other subjects may not need or need these features.

We are currently using Subversion. The structure is as follows:
/ trunk / is the main functionality common to all subjects
/ branches / REGION_1 / is the version with features for the subject REGION_1
/ branches / REGION_2 / is the version with features for the subject REGION_2
/ branches / REGION_N/ - version with features for the REGION_N subject
, etc.

The main difficulty is that with a large number of subjects with their own requirements, it becomes necessary to merge back and forth, and sometimes you can simply forget something, for example, not to merge some bugfix. It's hard to keep everything in my head, and the revision log grows to such a size that it takes time to check if I froze a bugfix. Also, for each subject, you have to update separate documentation, which also takes time.

Any advice on the best way to organize this? Is the folder structure correct? Are there any utilities that make project management easier?

The office is not very big, so far they are not ready to spend money on JIRA and similar systems.
If there are any articles on Redmine and other free systems, I will be glad to provide links.

ps And how is your development process organized? What additional utilities that make life easier do you use? It's very interesting to hear the answer.

Thanks in advance for your advice!

Answer 1

It seems to me that there is a more correct approach - branch by architecture.
That is, you implement in the IoC project and enable / disable the desired functionality through specific configs for each client.
The codebase is the same for everyone.
Refactoring can be quite expensive, but, IMHO, branch hell is even more expensive if there are a lot of clients.

Answer 2

If you take into account that you need to manage separate features in the form of separate branches (although in my opinion it’s better to do something with the product itself, maybe divide it into modules), then this simple solution came to mind:
* migrate from svn to git (I don't know if svn has a function similar to rebase in git)
* make separate branches in it, which all come from the master branch
* then when finalizing or fixing a bug, after checking it, you check it into master
* in all branches for regions that use this functionality, do a rebase relative to the master branch (in this case, it will take the latest version of the code from master, and overlay your new ones on top of them. In this case, the bugfix will be applied to all branches automatically thanks to rebas. If there are no overlays in the code, of course, otherwise, you will have to measure it with pens).
The solution is absolutely not perfect, just a train of thought formatted as an answer (:

Answer 3

to retran:
+1, only maybe you meant Branch By Abstraction
links here
continuousdelivery.com/2011/05/make-large-scale-changes-incrementally-with-branch-by-abstraction/
paulhammant.com/blog/branch_by_abstraction .html

Answer 4

My opinion is that all development (master) should be carried out in one branch.
The difference in functionality should be maintained at the software config level or during assembly.
In different projects, we have implemented both approaches - which one is preferable - decide for yourself, we chose the following as a criterion
:
How it worked:
* launched a configurator with plug-ins, which cleaned “everything superfluous” from the software
* then launched the assembler
* handed over to the client what was left
If you don’t feel sorry for the source code (or there is no fear that something extra will be included through the config), then it’s easier to embed everything into the full software. Those. distribute the fullest possible version.
A separate case is when similar behavior is required in the same situations, but with its own characteristics. To illustrate, I will give a stupid example, but I hope it is clear:
We need to enter information about the responsible person in the company. In option A) we are required to place everything in one field in an arbitrary format, because it is more convenient for them, and in option B) we are required to post everything in different fields: full name - separately, phone number - separately, email - separately, etc. P.
In this case, it would be nice to implement both and make a switch in the configurator, as described in the answer above: Branch By Abstraction - i.e. try to abstract some behavior and use and make it easier for yourself to connect the required module.