How best to organize the development process?

Good day!

Outline the situation:
There is a software product, this product comes to various subjects of the Russian Federation.
It happens that one of the actors asks to add (remove) any features you need (no need), but at the same time, other entities, these features may not be needed or desired.

At the moment we use Subversion. The structure is this:
/trunk/ — basic functionality common to all subjects
/branches/REGION_1/ version with features for the subject REGION_1
/branches/REGION_2/ version with features for the subject REGION_2
/branches/REGION_N/ version with features for the subject REGION_N
etc.

The main difficulty is that for a large number of subjects with their demands, there is a need to do merge here and there, and sometimes you simply forget something, like not smarriti some bugfix. Difficult to keep in mind, a revision log of razrastatsya to a value that to check, and if I samargol bugfix, takes time. Also, for each subject, we have to update the documentation also takes time.

Tips on how to better all this business to organize? Normal folder structure? Is there any utility to simplify management of the project?

The office is not very big, yet not willing to spend money on JIRA and similar systems.
If there are any articles on Redmine and other free systems, I will be glad to reference.

p.s. And how the development process do You have? What additional utilities that simplify life, use? Very interesting to hear the answer.

Thank you in advance for your advice!
October 8th 19 at 01:40
4 answers
October 8th 19 at 01:42
Solution
I think that's a better approach — branch by architecture.
I.e. you are implementing in the project of IoC and enable/disable the desired functionality through specific configs for each client.

Code base at the same for everyone.
Refactoring can be quite expensive, but, IMHO, branch hell — it's even more expensive if there are many clients.
And, Yes, throw in svn in any event ;) - eliezer.Bahringer commented on October 8th 19 at 01:45
October 8th 19 at 01:44
If you take into consideration that you will need it in the form of individual branches to manage separate features (although in my opinion, the best of something with the product itself to do might be to divide it into modules), it came to mind here is a simple solution:
* are migrating from svn to git (I don't know if in svn a function similar to rebase in git)
* it has separate branches that all come from the master branch
* then, when the revision or fix for the bug that after screening, you enter 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 a fresh version of the code from master, and on top of them will put your new. In this case, the bugfixes will apply to all branches automatically due to the rebas. If there is no overlap in the code, of course, otherwise will have to pomarici handles).

The decision is absolutely perfect, just the way of thinking, decorated in the form of an answer (:
To see how it works, it is possible according to the instructions in habrahabr.ru/post/123111/ - eliezer.Bahringer commented on October 8th 19 at 01:47
1) About the modularity of the product, thanks for the advice, I should think about it. Just don't suspect that will be such an influx of wishes from customers, the architecture will have to adapt :)
2) To Git the boss does not really want to go, although he is constantly looking in his direction - roslyn commented on October 8th 19 at 01:50
October 8th 19 at 01:46
Oh, really. Thank you for the correction. - eliezer.Bahringer commented on October 8th 19 at 01:49
October 8th 19 at 01:48
My opinion is that the entire development (master) must be done in one thread.
The difference in behavior to support at the level of config, or BY the Assembly.
In different projects we have implemented both approaches — which one is preferable — decide, as a criterion, we chose the following:
If the code is distributed with source code, which is a pity to give, we can use it at the Assembly level FOR the "Assembly level".
How it worked:
* run the Configurator with plugins, which were cleaned from the soft "all excess"
* then run the collector
* client passed, what is left

If the source code is not a pity (or fear that through the config would include something extra), it is easier to build everything in full. I.e. to distribute the most complete version.

A special case when required in the same situations behave similarly but with their own features. For illustration, we give a stupid example, but hopefully illustrative:
We need to make information on the responsible person in the company. In variant A) we are required to put everything in one field in an arbitrary format, because they are so convenient and variance B) we are required to carry on different fields: name — separately phone, separately, email separately, etc.

In this case, it would be nice both to implement and to make the Configurator on the switch, as described in the answer above: Branch By Abstraction — i.e. to try to abstract some of the behavior, and to use and to facilitate the connection of the required module.

Find more questions by tags Web DevelopmentSoftwareSubversion