I have a problem, I have several versions of the same application but the process of duplicating and managing several duplicate applications is becoming very complex, each copy gets unique features by client demand.
What methods are used to simplify this process?
Do I need to have detailed documentation about every App?
I'm trying to separate the code by modules and had them according to the clients demand, am I on the correct path?
Sorry for the bad English, any question just ask, I'm always online.
This can be managed in your code revision system. Git and Mercurial allow you to manage code as "change sets". You could have a branch for each client, and have a main branch (trunk) where you add features for everybody. In the client branches, you add feature sets for individual clients. If you want to merge them back to the trunk, you can. You can also merge from the trunk to branches.
Of course, it's important to develop in a modular way in order to facilitate this approach. Also, unit tests speed things along when you have to merge.
Related
I did a check if this has been asked before but the closest I found were questions around a single application with different branches for clients.
What is the best strategy for handling multiple applications in version control? Say I have 5 completely separate applications that can require changes at any point. Do I put them all under the same main trunk (origin/master if you will) then branch off as required or should they all get their own trunk?
Let me know if it's not described well and I can add more information.
You should see the Branch strategically:
When should the team add a branch?
You should create branches in the following situations:
When you must release code on a different schedule/cycle than the
existing branches.
When your code requires a different branch policy. If you create a
new branch that has the new policy, you can add strategic value to
your project.
When functionality is released to a customer and your team plans to
make changes that do not affect the planned release cycle.
You should not create a branching for each user story because it
creates a high integration cost. Although makes branching easy, the
overhead of managing branches can become significant if you have many
branches.
In you scenario, It's based on how do you want to manage the applications, different schedule/cycle ... then you need to track in another branch as David mentioned above. And if the size of applications are very large, you can even version control them separately in new team project.
This article for your reference : Branching and Merging: Ten Pretty-Good Practices
We are considering using Gerrit for the large project. At this point it would be interesting to know how people are dealing with merge conflicts of approved changes.
Imagine, that many changes of different size are pending revision simultaneously, and they are being reviewed and verified gradually. Since some of them might be modifying the same piece of code, the conflicts are inevitable. It is not a problem if "integrator" accepts patches manually in a simple workflow, small conflicts can be resolved on the way, but with Gerrit things are different. When the change has been reviewed and approved, in case of merge conflict, as I understand, it will need to be rebased by the author and pushed for revision again, in which case revision process starts again. In the relatively active projects, with more than 50 external contributor commits per week, this might turn into nightmare, if revision of the same patch might be required to be done several times due to merge rejection after each approval and submit, which seems to be not efficient.
Questions:
Am I correct that Gerrit is not a way forward for the large and active stuff where the large number of merge conflicts is expected?
Some merge conflicts can be trivial, is there a way to resolve them without the need of bothering author to recommit the change?
If the change needs to be backported to stable branch(es), I guess the separate change for each branch needs to be pushed for revision, even if the cherry-pick is clean.
General comments about your Gerrit workflow experience are also welcome.
Gerrit is used by some really massive projects, such as Android and the related bsp, kernel, etc repositories. These projects get way more than 50 external commits per week. I think Qualcomm will have several thousand commits in about that amount of time.
There is a setting in Gerrit to auto-merge trivial conflicts. This can be set per-repository. If this option is set, the change is merged in based on your submit strategy (cherry-pick, merge if necessary) after the change has been reviewed and verified and a user presses the 'Submit' button. The best documentation I could find for this is here http://gerrit-documentation.googlecode.com/svn/Documentation/2.3/cmd-create-project.html#_options under the --use-content-merge option.
Yes that is typically how we do things. There are other options (bypassing review, merging branches, etc), but cherry-picking to the needed branches and reviewing works well.
We want to keep our history clean and understandable, and therefore reasonably linear. So we have configured Gerrit to use only fast-forward merging. The only visible merges are for release and support branches (we're using git-flow) which makes things much easier to understand.
However, we have the trivial-rebase plugin installed so that previous review status is automatically applied to the rebased change. This happens regardless of whether rebasing is done in Gerrit (using the Rebase button) or by the developer rebasing locally and re-pushing the change.
In our experience, merge conflicts are actually less common in a large project, due to the much larger number of source files involved. We have around 16,000 files in the repo and 30 full- or part-time developers, so the probablility of editing the same file is quite low.
In any case, if two developers are making changes to the same part of the same file, they really should be talking to each other. If the project architecture requires frequent changes to the same file (eg a registration table of some kind) the architecture needs to be redesigned, to use something like dependency injection, or to generate that source file automatically from fragments as part of the build.
When we hit a merge issue at our company, the developer rebases and pushes to gerrit. If the merge was minimal, he's allowed (by convention) to LGTM the rebase and submit.
We are still debating if/when developers should rebase when updating patchsets. The UI gets confused when comparing between patchsets when the parent changes.
I'm using it for a few weeks after using mercurial for a couple of years with a feature branch merged into default mode and I'm hating gerrit. I find myself with more overhead solving trivial conflicts that are solved automatically by merges on mercurial or git in non-gerrit mode. Then everybody uses the argument android uses gerrit ergo gerrit is good and should work for everybody.
I am pretty new to TFS and source control. I unable to understand the advantage of branching. Since i can do the same stuff by creating 2 folder main and development, when I am done with development.I can merge the code using any diff tool with the main branch.
Then whats the point of having branches ? I know there must a huge advantage but i am unable to understand.
(UPDATE: TFS now supports git for version control so the rest of this answer no longer applies)
I would google branch-per-feature.
The main advantage of branching is that you can work on a feature and not be interrupted by anyone else's work. When you are ready, you can merge and see if many features work well together or not. This is usually done as the feature is developed but for small features can be done once the feature is complete.
The advantage is that you have a clear history of what you did to implement something. Without branches, you would have a whole lot of commits mixed together with other features' commits. If QA does not pass a certain feature, you have your work cut out for you to put together another build using just the commits for the other features. The other alternative is to try and fix your feature so that QA passes. This may not be doable on a Friday afternoon.
Feature toggles are another way to omit work but this increases the complexity of code and the toggles may themselves have bugs in them. This is something to be very weary of and see how this became an "acceptable" work-around.
Branches are also used to track changes to multiple versions of releases. Products that are consumed by multiple customers may be in a situation that one set of customers is using 1.0 of the product while others are already on 2.0. If you support both, you should track changes to each by branches that are designated to them. The previous points still apply to developing for these branches.
Having said that, TFS is not ideal at branch-per-feature for a number of reasons. The biggest is that it does not support 3-way merges - it only has what is called a baseless merge. The way history is tracked, TFS cannot show you a common ancestor between the feature branch and where you are trying to merge it to. This leaves you potentially solving a lot of conflicts. In general, a lot of people that use TFS shy away from branching for this reason.
3-way merges are great because they will show you what the common ancestor is, what your changes are and what the changes in the other branch are. This will allow you to make a very educated decision on how to resolve a conflict.
If you have to use TFS, I would suggest using git-tfs to be able to take advantage of 3-way merges and many other features. Some of them include: rerere, rebasing, disconnected model, local history, bisect, and many many more.
Rebase is very useful as it allows you to alter a feature to be based off of another starting point, omit commits, squash commits together, split commits, etc. Once ready you can them merge into an integration or release branch, depending on the workflow you decide upon.
Mercurial is also another one that may be easier to use, but will not be as powerful in the long run.
If you have the opportunity, I would highly recommend moving away from TFS for source control due to a lot of limitations when compared to modern day DVCS.
Here is a nice set of guidelines to follow if you want to effectively manage branching/merging:
http://dymitruk.com/blog/2012/02/05/branch-per-feature/
Hope this helps.
There is a lot of information to read through, but there is TFS Branching Guidance located here if it helps at all - http://tfsbranchingguideiii.codeplex.com/
I’m writing an application with Ruby on Rails. This application will be delivered to a minimum of two different customer types. The base is always the same but some of the views differ. That’s mostly it. For now.
Is there any way, for example using branches, to use the same code base and separate only the views, for example? I read the Git manual for branching but am still not sure if this is the best way to achieve what I need.
Another idea would be forking. But, is that clever? If I change something in the code of fork A, is it easy to merge these changes into fork B?
Branching and forking in git is not bad at all, as the merge support is great (possible the best of al VCMs).
Personally, I don't like the idea of branching or forking a project to provide different customization as it can very quickly become really difficult, e.g. what are you going to do if you have 15 different deployments?
I think a better approach is to build the application so it behaves differently depending on some parameters. I'm well aware that sometimes the implementations are very different, so this might not be useful anymore.
Another approach is to build the core of your app in a GEM which acts as a service to the application, and the only thing you customize per client are the views. Of course, the GEM should be generic enough to provide all the services you need.
Please share with us what you decided, as there's no best answer for your question.
It would probably be better to make you product select between the types at either build or runtime, that way you can use a single set of source.
Otherwise it is possible with branches, and merging, but you'll have more difficulty managing things. Forking is basically branching at this level.
I agree with #Augusto. You could run your app in 2 different environments, ie production_A and production_B. From there, you could use SettingsLogic to define configurations based on Rails.env, then reference those settings in your app when selecting which view to use for example.
I am currently a single BI developer over a corporate datawarehouse and cube. I use SQL Server 2008, SSAS, and SSIS as my basic toolkit. I use Visual Studio +BIDS and TFS for my IDE and source control. I am about to take on multiple projects with an offshore vendor and I am worried about managing change. My major concern is manging merges and changes between me and the offshore team. Merging and managing changes to SQL & XML for just one person is bad enough but with multiple developers it seems like a nightmare. Any thoughts on how best to structure development knowing that sometimes there is no way to avoid multiple individuals making changes to the same file?
SSIS, SSAS and SSRS files are not merge-friendly. They are stored in an xml file that is changed drastically - even with minor changes (such as changing a property) - so it becomes really impossible to merge.
So stop thinking about parallel development on one file. You need to think how you can achieve that people are not need to do parallel development on one file. So start with disabling the multiple checkout of a file. You might even want to consider to enable the option to get the latest version on a checkout.
Then start thinking how you can achieve that people can work independent. This is more in the way you structure the work and files:
Give people their own area they can work on. One SSIS package is only developed by person X at any given moment in time.
Make smaller files so the change that two people need to work in the same file is small.
I have given feedback to the product team of the imcompatability of BIDS to merge. It is a known issue, but will be hard to tackle. They don't know when it will be possible to really do parallel development on these files. Until then keep away from parallel development.
As Ewald Hofman mentioned, SSAS and SSIS is not merge-friendly.
In one environment I worked solved the problem as follows:
do only use SSIS when you have to (fuzz algorithm or something similar). Replace SSIS packages as often as you can with SQL code (see Linked Server for datasync. and MEARGE Command for dimension/fact-table-creating for instance).
build your data warehouse structure as follows:
build 2 databases, one for the "raw source data" from the source systems and one (the "stage" database) for the dimension and fact views and tables
use procedures that can deploy the whole "stage" database
put the structure for the "stage" database into your Repository
build a C# application that build your dimensions and cubes via the AMO API (I know, that's a tough job at the beginning but it is it worth - think on what you gain - Look at the Pros below )
add the stage database and the C# application to your Repository (TFS/Git etc.)
Pros of that structure:
you have a merge-able structure you can put in your Repository
you are using the AMO API witch has
you can automate the generation of new partitions
you can use procedures to automate and clone measure groups to different cubes (what I think is sometimes a big benefit!)
you could outsource your translation and import it easily (the cube designer is probably not the best translator)
Cons:
the vendor would probably not adapt that structure
you have to pay more (because of either higher skill requirements or for teaching him your individual structure)
you probably need knowledge over a new language C# - if you don't already have
Conclusion:
there are possibilities to get a merge-friendly environment
you will get lost of nice click-and-run tools f.e. BIDS - but will get into process of high automation functionality
outsourcing will be maybe unprofitable because of high individualization
http://code.google.com/p/support/wiki/DVCSAnalysis
maybe a better tag is DVCS?
https://stackoverflow.com/questions/tagged/dvcs
As long as both teams are using bids and TFS this should not be a problem.
assuming that your tsql code is checked in to source control in a single file per object, merging TSQL code is straight forward since it is text based. I have found the VSTS Database projects help with this.
Merging the XML based source files of SSIS and the MSAS can be cumbersome as you indicate below. to alleviate some of the pain, I find that keeping each package limited to a single dataflow or logical unit of work helps reduce developer contention on packages. I then call these packages from one or more master packages. I also try to externalize all of my tsql source queries using sprocs, view or udfs so that the need to edit the package is further reduced. using configuration files and variables also helps to a smaller extent.
MSSAS cubes are a little bit tougher. My best suggestion is to look into a 3rd party xml differencing tool. I have been able to successfully merge small changes use the standard text based tools but it can be a daunting task.