We have a project with multiple customers. Suppose application name is Ali-Systems. Foo company will have Ali-Systems Foo, Bar company will have Ali-Systems Bar and so on. All versions have almost same structure. But their logic are different. For example there's a BillIssue method for all versions, but its logic may be different. Either how to calculate or even the difference between their DB models(we are using ASP.Net MVC Entity Framework)
As I understand there is some branching strategies categorized by Microsoft like Development Isolation(which enables
concurrent development of the next release, experimentation, or bug fixes), Release Isolation(which enables concurrent
release management), etc.
Can I take advantages of Branching for this purpose and how? Or I should create separate repository for each customer's project?
NOTE : In fact I want to clone the base of a project to some derived projects which will never merge again together. But we must able to add features to all derived projects(probably with help of another branch)
Microsoft has Visual Studio Team Foundation Server Branching and Merging Guide , that can be used to choose the branching structure. Including Main Only,Development isolation,Feature isolation,Release isolation,Servicing and Release isolation,Servicing, Hotfix, Release isolation...
In your case, the core of the project, is similar , but for each company has its own personalization of the product(logic / DB models ), and maybe will evolve independently in the future.
Using some branching structure, the main limitation it becomes a maintenance nightmare for solving bugs and global changes.
For example, if you want to merge changes from one company to another was very complex and it required retesting each version separately . Moreover, for bug tracking, one team will solve the bug in their version and another team will have to merge that change from the version they don't fully understand.
To support such development scenario suggest to share extensible core
and data model which will be configurable from upper customizable
application layers. This core should be used as the base for each
customer/company specific customization and maintained by separate
team(for each company). It will include some management complication
because multiple project managers may need resources from the same
team but it is a good way to make architecture consistent, control the
whole process and keep versions in sync.
Besides ,if a person or team need to work across multiple companies in the local machine, one way to keep the local environment clean is Using multiple workspaces with Visual Studio
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 have a five-member development team and will be building multiple internal projects in parallel. Upon researching, I find it is best to create one team project, even for our situation, correct?
If so, would you please recommend how to set up proper iterations for the projects and timelines?
TFS question - small team, multiple projects sounds similar to my situation, but I can't seem to get more than one "current" iteration in the TFS Agile process board.
Per team project you can have only one iteration tree (and therefore only one current iteration). You should decide based on how you plan your team resources. Do you want to have only a single backlog for the whole team or different backlogs for each project?
Each has its pros and cons, depending whether you want to use Visual Studio Team Service mainly for planning your team resources or planning your projects.
Using a single team project / backlog
With this approach it is easy to plan your whole team's resources for the next sprint. You can assign people to different tasks in different projects and have a good overview on what the team currently is working on. To assign work items to different projects you can use the area path.
Planning and tracking the progress of individual projects is a little bit harder with this approach since you have the same iteration structure for all projects and also only a common set of tags.
There are external tools which can integrate with Visual Studio Team Service available from the marketplace though, which can help you with planning individual projects.
Using a team project per project
With this approach you have a clear overview of the progress of each project and you can have individual iterations, tags, etc.
On the other hand it's harder to plan your team's resources since you won't have a single backlog and no place to see what your team is working on at the moment at a glance.
You can create one team project and set several child projects in it. With this, you can have the things configured for the whole project and also the child projects. Refer to this link for details: Multiple teams
In the recent versions of MSF for CMMI there's a new work item type: Feature.
Theoretically, a feature contains some requirements as its children and, it defines a portfolio.
While integrating with project server, is it a good practice to use just Feature and Task work item types for sync?
I would start by sating that it is not good practice to sync with Project Server at all. However if you must...
You should not have hierarchical requirement's in TFS. So Feature gives you the ability to break Feature into Requirement into Task. So in that case you should sync all three levels.
If you look at the recently released Safe templates you should see Epic->Feature->Requirement. Accepted convention is that Requirements fit in a single iteration, Features fit in a single release, and Epics are bigger
So you can look at it as a scoping thing. If you are using project server to manage non-engineering work then you want to sync whatever is in scope for your project and sync it below the "Engineering effort" project task. Most orgs sync to the level of Requirement but not Task.
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.
My company is a Software development company.
We planned to use TFS 2010 for our future customers development.
TFS 2010 introduce Team Project Collection in order to split related Team Projects.
So my question is, should i use Project Collection per Customers or should i use a unique Project Collection with a Team Project per Customers which will contains some customer solution projects in it
It depends on how independent your projects and customers are.
For example do you what change set number series to increment within a project, per customer or within your farm? See the following link for some of the implications:
http://blogs.msdn.com/bharry/archive/2009/04/19/team-foundation-server-2010-key-concepts.aspx
Here's what we've decided to do, since we're a pretty small company...
We're going to have very few collections. Our primary collection is called "Production" and we'll have a few others called "Playground", "Proof of Concepts", and "Educational References".
The reason for doing it this way is that our rules/workflow/data needed for work items/etc. for how we handle things is very consistent company-wide and rather than recreating this customized configuration for many different collections, we'll just use different projects for that. The collections will be for when we need to go by different rules (for example, there will probably be no check-in requirements in the "Playground" collection but there obviously will be for the "Production" collection.
So in case it's not obvious at this point, it sounds like a different project per customer is what I'm suggesting for you. But of course, it really depends on your company, how large you are, how similar your project management style is (if you do CMMI for some projects and agile for some others, you might want to separate them), and some other needs.