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
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.
eliezer.Bahringer answered on October 8th 19 at 01:42
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.
roslyn answered on 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 (:
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.