Whats the right method of version controlling my product?
I am using TFS and visual studio 2010.
Currently I am working alone on my project, so its not a team management workflow.
I don't think that I should use an agile workflow because of the reason above.
But I do want to handle builds and know what has changed between each build.
Thanks.
I dont think that a one man project is a reason to not go the agile way, but it's up to you and your decision.
(I define all my projects which I am developing alone with the Scrum Template.)
If you want to know what changed between each build you need to checkin against your work items.
So select a project template which fits for you, define your work in the workitems (task, backlog or user story, wording depends on the project template).
To not checkin without assigning against a workitem you can activate a checkin policy, so TFS will throw a dialog as a reminder.
Related
I'm trying to get my head around how to best organize my companies code set in visual studio 2013 TFS-git. We have multiple database projects and multiple web application projects. I like the idea of being able to develop a web app and the db at the same time in a particular solution but its not a one to one scenario. Multiple web apps talk to the same databases.
I know you can break things up into solutions and projects but not seeing too much out there in best practices in this area.
Any guidance? Thanks for your help.
I think this will help you what you are trying to do
Git init VS full Git support into all their ALM products. Here they have published for Visual Studio that adds Git source control integration. Git Extension includes add-ins for Older Visual Studio versions and Windows Explorer integration. It's regularly updated. And alternatively you can look for Git Source Control Provider
And you may also a read about TFS-GIT here
TFS 2012 includes excellent support for code-reviewing changesets. However, we have some legacy projects that we want to code review. Once the quality has been brought up to spec, we will start using changeset reviews - however the code changes infrequently, so it's not practical to just review the changesets and improve quality through natural code-churn.
Is it possible to code-review a file or project in it's entirety, rather than just a changeset?
In TFS 2012 this is not an option. If the project is small enough there is a trick, you can right-click the folder in source control, do "checkout..." and then request the review. That allows you to review up to 4000 files at a time.
In TFS 2013 a new feature was added, Lightweight Code Commenting in Web Access. This allows you to annotate the code directly from the code tab in Web Access.
There are 3rd party code review options available on Codeplex, I haven't used them in quite a while, but they might add something more to your liking:
Team review
Team Code Review Workflow
Malevich
Has Microsoft addressed the difficulty of creating a SP site after creating the Team Project in TFS 2012? I am aware of the methods outlined here, but I was hoping they had come up with something slicker in the new version. If not, does anybody know of a better method or tool than the one suggested in the previous link?
The TFS Power Tools has a command tfpt addprojectportal that will create the SharePoint site for you after the Team Project has already been created. You will need to know process template that was used to create the team project. You will be able to find all the options you need for the command by using the /? switch.
Can I have some basic project management in Visual Studion without TFS or is TFS what I need?
Basically I like to get a list with my projects, last edited dates, and if possible project tags (customer for example), and when selecting one VS should load it. From the right repository (Mercurial/Git/Svn). I can move my project to some repo host if they have this solution (Addon).
At the moment I handle the projecs manually with Windows standard folders + SVN/Hg in folder context menu, and thats a headache.
Thank you
As far as I know Visual Studio doesn't support that functionality natively.
TFS isn't my forte but I know it comes with MSDN subscriptions and the retail version is around $500 if that is the path you are interested in. If you do go the TFS route you have an option to use TFS Basic during install which is a greatly simplified install of TFS that can even use SQL Express.
You can check out pricing and download the trial from here if you want more info:
http://www.microsoft.com/visualstudio/en-us/products/2010-editions/team-foundation-server
We recently migrated to TFS 2010, and have created a new Team Project. (The old one was created in 2005, and seems to be missing key metadata to allow full functionality in 2010). We've copied all our source, and have figured out how to copy our work items to the new team project, but we can't figure out how to migrate our build definitions.
Is there a way to do this, or will we have to re-create them manually?
Thanks!
[EDIT]
Jeff-thank you for the reply! After reading it, and more deeply considering my situation, I realize that my description (and probably my entire question) was flawed.
We originally upgraded our 2008 team project to 2010. It had previously been upgraded from 2005. Up to this point, we've been using CruiseControl.Net to manage our builds. One of our team noticed that our upgraded project was missing some key metadata, and theorized that stuff had not been added in the migration process, so he created a new 2010 team project and imported our source as a test. Now we have two 2010 team projects: the originally migrated one (that we're all using), and the "from-scratch" one.
In the meantime, I was experimenting with TFS Build on the originally migrated project. I created a dozen or so builds, and was refining them, but we haven't moved off of CC.Net yet.
The decision was made to start using the "from-scratch" project, so I was hoping to somehow copy the builds from one project to the other. I don't see a way to do that... there is no build proj file to copy (TFS seems to keep the build definitions internal in 2010).
Normally, when you upgrade to TFS 2010, any build definitions you previously had will be automatically upgraded with the associated Team Project. It sounds like, at least in your case, that your Team Project did not upgrade completely/correctly so you had to start over with a new Team Project.
To copy your build definition, you will need to:
Copy the TFSBuild.proj file(s) from your old Team Project to the new Team Project - under whatever version control folder makes sense.
Create a new TFS 2010 build and select the Upgrade Template (in the Process tab).
Set the Configuration Folder Path property to the location of the copied TFSBuild.proj file copied in step 1 above.
Fill in the remaining required settings.
Hope this helps.
There's been significant changes to how builds are done from TFS 2008 to TFS 2010. One of the reason's why it appears that 'stuff has not been added to the migration process' is because it just does not exist. Even upgrading from TFS 2005 to TFS 2008 had a bit desired in it's completeness.
Jeff provided some good guidance to use the Upgrade Template, this will actually call the tfsbuild.proj file that was carried over from TFS 2008.
As a good practice, you'll want to create a copy of the DefaultTemplate when a new build definition is created for a corresponding relationship. Do this while creating the build definition in the process part of setup. There is a detail expansion arrow that will allow you to create a new, which is a copy of the default, and name it whatever you like. Unless of course there will be absolutely no customization done to the build definition or all of the builds in that project will be following exactly the same steps. i.e.: dev_sso_ci (build definition) corresponds to dev_sso_ci.xaml in the BuildProcessTemplates folder.
Hope this helps too.