New to VSTS, but not Git. Our small team has the usual mix of web apps, windows apps, other misc applications/services and we keep our database objects in visual studio sql server projects as well. So there are 15-20 or so different sets of code to deal with. Currently, each would have its own Git repo.
Was reading this post regarding single vs multiple "Team Projects".
Then, I posted this earlier but was specific to backlog items, but I suppose my real question was about the bigger picture regarding the idea of a "team project"
What would be a good structure for a small team with this number of applications. Assuming each application generally is worked on independently, but you might want to build 2 or more of these applications together.
How about one team project. Multiple "teams", one per "application".
Its the terminology that is throwing me off.
Can different teams each use a different repo?
Can each team have a different set of build definitions? eg. dev/prod etc
A team project is a container for a portfolio of related applications. A team project can contain one or more source code repos (Git/TFVC), builds, releases, test cases, work items, etc. All of these entities have ways of defining security around who can view/modify them.
A team is just an organizational structure within a team project. You can use security permissions to limit certain repos, builds (or build folders), etc to a certain team.
The generally accepted guidance is to keep everything in a single team project. There are lots of things that don't cross team project boundaries, such as repos. Work-arounds usually exist, but they are typically awkward.
The one requirement you gave ([we] might want to build 2 or more of these applications together) is actually slightly tricky regardless of whether the repos are in one or in multiple team projects -- a build definition can be hooked up to a single repo. If you need to bring in additional repos, you'll need to use submodules or add an extra build step to clone the second repo. I can almost guarantee it'll be easier if everything is in the same team project, though.
The one-word answer to the two direct questions you asked is "Yes."
How you set up your structure is really depending. There are many ways to organize it. Single repo, multiple repos.
If you are using CI builds, have in mind that the get sources task in your build will download your full repo. So if you have a single repo strategy your build could take longer to run. In this scenario you would also have more work to setup your builds and specify path filters to trigger only the correct build on your CI process.
Can different teams each use a different repo?
Yes they can.
You can create a security group for each team.
Then, on you team you can remove it from Contributos and add your new group as part of Member of:
After that, in your version control settings, add your new security group and remove or deny access to Contributos security group. This way, only your team security group will have access to the repo.
This is optional. You only need to do it if you want to isolate access to your repos.
Can each team have a different set of build definitions? eg. dev/prod
etc
You can setup a build for each of your repos.
If you need to isolate who has access, you can do it by changing the security on each build, removing contributos and adding your security group.
Related
I tried a few searches related to this questions on here and didn't see something similar.
As part of a bootcamp I am working on, I have a few mini-projects I have to submit. These projects take between 2-10 hours to complete and typically only contain 1-5 files each. I've seen other students have separate repositories for each of the projects, which allows them to have a clean readme.txt. Initially, I grouped these mini projects into folders within one repository dedicated to these mini projects to reduce clutter. So I can see potential advantages to either approach. At either rate, these small projects were designed to demonstrate very specific skills that are relevant to future employers, so I want them to be available for inspection.
So is there a "best practice" if I am intending to use GitHub as a portfolio of my code? Would it be better to declutter my repositories by keeping small projects together so my bigger projects can shine? Or to separate them so each project is readily in-sight?
have separate repositories for each of the projects, which allows them to have a clean readme.txt.
You can have a clean readme.txt/readme.md with one repo, which would:
explain what the subfolder represents
list your subfolders
link to sub-readme.md (one readme.md per subfolder, per project)
That being said, you can create an account dedicated for this bootcamp, and keep your repos separate, that way you avoid the clutter with your main GitHub account.
Still new to VSTS. Sometimes work or requests come in and our team needs a way of sorting these into areas that will become projects, but not immediately. Can I create a task without first creating a new team project?
Also, is there a way to see different projects at a higher level than the tasks in one view on a kanban board? Ive seen some delp docs on dashboards etc, but everything including tasks are all scoped to a team project. While this makes sense to have these things for a project, but what about higher level views? At any one time, there might be 4-5 different projects being worked on as well as 2-3 different things that are not part of a project yet. Maybe VSTS isnt the place for these more general items, but a generic kanban board?
The term "team project" is kind of an antiquated name that doesn't do a great job of accurately describing its purpose. Think of a "team project" as a portfolio of related applications rather than something for a single team, or a single project.
The most common way to address is this to keep everything in a single team project. There are a lot of things that don't cross team project boundaries, and trying to force that behavior is a recipe for frustration.
Within a team project, you can create Teams. Each team can have its own backlog, its own iteration schedule, etc. Teams are assigned an area path that they own. If a work item is under their area, it's assigned to that Team.
If you have Team A's area path set to FooProject/Team A, then it belongs to that team. A work item under FooProject/Team A shows up on that Team's backlog.
From there, you can adjust security permissions and such so that if a person isn't a member of a given Team, they don't have access to see or manipulate other teams' work items.
I would like to know if I have a project, and I want to create a separate test and release projects/branches.
Shall I create one team project and then create branches like test, dev and release?
OR can I also go for a separate team project for each?
One of our clients have been using separate team projects for each.
Could you elaborate under which circumstances shall we opt for a team project instead of a branch? What are the pros and cons of each approach?
To the best of my knowledge, I think branches should have been used in this scenario.
Thanks for your help.
A new branch will provide merging and build options that can't be done from one project to another. If you create branches you can share work items (tasks, bugs, ...) between all of them, if you create projects, developers will need to go to each project to find tasks, etc.
Usually it's better to crate branches for each environment. If you go for team projects make sure there is a good reason for it.
Take a look to this article, it may be helpful:
http://nakedalm.com/when-should-i-use-areas-in-tfs-instead-of-team-projects-in-team-foundation-server-2010/
Branches should be just fine, no need for multiple team projects.
I am in the process of moving to Git from SVN. In SVN I had multiple eclipse projects in a single SVN repository that is convenient for browsing projects. I was going to move to having one git repository per eclipse project but EGit suggests doing otherwise.
The guide for EGit suggests putting multiple projects into a single Git repository.
Looking at similar questions such as this suggest one project per repository.
Which approach is best practice and what do people implement?
It depends on how closely-related these projects are. Ask yourself the following questions:
Will they always need to be branched/tagged together?
Will you want to commit over all projects, or does a commit mostly only touch one project?
Does the build system operate on all of them or do they have a boundary there?
If you put them all in one, some things from above will be easier. You will only have to branch/tag/stash/commit in one repository, as opposed to doing it for every repository separately.
But if you need to have e.g. separate release cycles for the projects, then it's necessary to have each project in an independent repository.
Note that you can always split up a repository later, or combine multiple repositories into one again without losing history.
Combining is a bit harder to do than splitting, so I would go for one repository first and see how it goes.
I use 1 repo per project.
Some reasoning:
When you discover you messed up something after several commits, it's much easier to fix when it's just one project. Just think about, you did commits to two other projects and now you need to fix the commit you did on the 3rd project.
As Fedir said, your history and log is much cleaner. It only shows the commits for that project.
It works better with the development workflow I have. I have a master branch for production, develop branch for, well, development, and I create branches to implement features (you can read more about it here: http://blog.avirtualhome.com/development-workflow-using-git/)
When you work in a team, and so "share" the git repo, do the team members really need all the other projects as well?
Just a few thoughts, but what it boils down to: Do what works for you.
I have multiple projects (Eclipse projects) and have tried different things to find out what worked best in terms of actual daily development. Here is what I found and I think that most people would find the same thing if they kept track of the results and analyzed the results objectively.
In short applying the following rules will give the best results:
Make a separate repository for each project group.
Each project group consist of a group of projects that are tightly connected to each other, that should be administered together and that cannot be easily decoupled from each other.
A project group can contain a single project.
A project group that contains multiple projects should be examined to see if some of its projects can be decoupled from each other so it can be split into smaller project groups that are still contain projects that are tightly connected to each other, that should be administered together and that cannot be easily decoupled from each other.
The following guidelines explain this process for determining which projects to put in the same repository in more detail:
If a project is not closely connected to any other project (for example, the project can be opened without other projects being opened and no other projects relies on the project being opened when they are opened) then you should definitely place it in its own repository for the reasons explained in the answers above this one.
If a project is dependent upon other projects or other projects depend upon the project then it comes down to exactly how connected are they upon each other, how well they can be packaged together and how easily can they be decoupled from each other.
A) For example a testing project that contains junit test classes to test the classes of a main project is a case where the two projects are very connected with each other, can easily be packaged together and cannot be easily decoupled from each other. These projects should be placed in the same repository for the reasons explained in part C below.
B) In a case where one project relies on another project to provide some sort of shared resources it really comes down to how well that they can be administered together and how easily that they can be decoupled from each other. For example if the project with the shared resources is relied upon by many projects, then it should be put in its own repository because the other unrelated projects are impacted by changes to the shared source code project. In a case like this, the shared resources project should be decoupled from the dependent projects instead of being directly connected to the dependent projects. (For example, it would be better to create versioned archive files [Jar files with a name like "projectName".1.0.1.0.jar for example] and include a copy of those in each project instead of sharing the resources by linking the projects together.)
C) If the multiple projects are connected, can be easily administered together but cannot be easily decoupled from each other, then it depends upon how tightly connected they are with each other.
I) If the projects are put into one repository, then the projects will be kept in sync with each other in the repository each time there is a commit, which can be a real life saver if the projects are tightly connected. However, this also creates the issues noted in the answers above this one.
II) If the projects are put into separate repositories, then you will have to take care to keep there commits in sync with each other and be sure to include some sort of mechanism to indicate which commits belong to the same sync point across the projects (Perhaps something like including the same sync point number in the comments for the commit of each project when a group of commits is done across the projects.)
III) So in cases like this, it is almost always better to put these projects together into a single repository to reduce the overhead of human effort in syncing the commits and to avoid human error should the commits need to be backed out. The only time that it might be better to place them in separate repositories is when only one of the projects is being changed regularly and the other connected projects are rarely changed.
I think this question is related to one I answered here. basically Git by its nature supports a very fine granular structure when it comes to projects/repositories. I have read and been taught that 1 repository per project is almost always best practice. You lose almost nothing by keeping the projects separate and gain a lot as other have been describing.
Probably, it will be more performant to work with if You will create multiple git repositories.
If You will make a branch, only project's files would be branched, and not all the projects.
Small project it will be faster to analyze, to commit. Operations will take less of time.
The log will be more clear also, You could make more granulated configuration if You will have multiple git repositories.
I have a client who is using one TFS project just for source control only and now wants to manage work items in a totally different TFS project, using a different process template, and intends to link changesets to work items across TFS projects.
I know that this is possible in TFS, but don't know what the limitations or issues that come with this configuration. e.g Build Summaries, Reporting, etc.
I would prefer branching the code into a new TFS project and managing code and work items together in one project, but need to know how the above method stacks up.
It'll work - I've occasionally had to associate checkins with work items from other projects. I haven't noticed any issues with reports or the like, that said this seems like an overly complex arrangement with little benefit.
Seems like a strange set-up to me. While it will work, TFS is designed for the check-ins and work items to be in the same team project so you won't really get the full benefit of the TFS features. Does the client know that they can modify the process template of the existing team project or do what you say and branch or even just move the source into a new team project.
We used this model to allow us to have separate projects but against the same source branch. It worked for a while but once we started being more adventurous with branches the model broke down. So as others have noted, there's no reason why technically you can't do this, it's not standard.