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.
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.
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.
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'm currently using Bitbucket for my Mercurial repositories and it's working great. I would however like to be able to organize my repositories in folders, as having them all in one long list is a bit disorganized for my liking.
To be clear I'd like to be able to access my repositories kind of like this:
hg clone https://username#bitbucket.org/username/foldername/reponame
While (AFAIK) it is currently only possible to use a single reponame, no foldername.
Is there any Mercurial hosting provider that does this, or is there some other method that might help me organize my stuff?
I'm aware of subrepos and I might look into that, but it seems like a hackish solution to my problem (also one of the clusters I am working on uses an ancient Mercurial version from way before subrepos were added). Another possibility would be to have multiple user accounts for Bitbucket, but again that doesn't really scale well (I don't want to wind up with 10 accounts).
You will have to use separate repositories.
Kiln has a nice interface that supports multiple repositories.
Organize Your Code
Start simply by just creating the repositories you need for your
code. Kiln introduces branch repositories, repository groups, and
projects to help keep things organized as you develop your own
workflow.
...
Repository Groups and Projects are there to help keep related code
grouped together. Whether your software project is large or small, it
can be really helpful to separate different parts of the code into
different repositories. What used to be accomplished with complicated
naming schemes is now accomplished with simple labels and
drag-and-drop organization.
Kiln (kilnhg.com) has a concept of projects and groups for organizing repositories along with several other really cool features.
It is a commercial product, however. (Your question didn't mention whether or not that was a problem for you.)
The only way you can obtain this using Bitbucket is to create a single repository named "foldername" and put the sub-repository inside this 'root repository'. This however is not the best practice according to the mercurial philosophy. Also, you will have a single bitbucket panel as per a single repository.
You can then use the mercurial feature Suprepositories to manage the whole collection:
https://www.mercurial-scm.org/wiki/Subrepository
Read about the kind of layout you are looking for here:
https://www.mercurial-scm.org/wiki/UnderstandingMercurial
(point 6, at the end of the page)
Of course you can setup your personal mercural server to do this, but is a little bit tricky and I discourage it. If you wanto to try, you can start from here:
http://ekkescorner.wordpress.com/blog-series/git-mercurial/step-by-step-install-mercurial-server-on-ubuntu/
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.