How do I change process template to MSF for Agile on an already existing team project in TFS 2010?
We have upgraded our TFS 2008 to 2010, and now I would also like to change the process template to MSF for Agile (currently CMMI).
We haven't used the workitem functionality much so if some information gets lost in the conversion doesn't matter.
Once you've created a Team Project, you unfortunately can't just upload a new process template. As Robaticus says, you'll have to download the XML for the template and modify it, then re-upload it. The power tool lets you create NEW templates for NEW team projects, but it won't modify an existing one.
Instead, you can use the witadmin.exe tool (on any computer with Team Explorer installed, under \Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE, or just from a Visual Studio Command Prompt) to export the current workitem definitions and re-import them once you've made your changes.
Luckily, if you're not using workitem tracking much, then this might not be too difficult. You might be able to just delete all the existing workitem types and then re-upload the new types.
If this is too much trouble, consider how much you want to retain your source control history. It might be worth creating a new Team Project with the Agile template and then just moving all your source code into it.
You can't change the process template, however you can change the work item types. So for bugs, tasks you can swap to the Agile definitions.
You can do this in 2010 with witadmin, in 2008 it's importwit, by first downloading the template to disk (you'll need the TFS power tools for this). Then point the console app at bug.xml, task.xml etc..
Usage: witadmin importwitd /collection:collectionurl [/p:project] /f:filename [/e:encoding] [/v]
/collection Specifies the Team Foundation project collection. Use a fully specified URL such as
http://servername:8080/tfs/Collection0.
/p Specifies the team project in which the new work item type is imported. This is required, except when
the validation-only option is used.
/f Specifies the work item type XML definition file to import.
/e Specifies the name of the .NET Framework 2.0 encoding used to import the XML file. For example,
/e:utf-7 will use Unicode (UTF-7) encoding. Encoding is automatically detected whenever possible. If
the encoding cannot be detected, UTF-8 is used.
/v Validates the XML definitions for the work item type, link type, or global workflow without importing
them.
You can export the agile process template to disk, then import the work items into your existing project. You may need the TFS Power Tools to do this.
I may be too late for this question, but the TFS Integration Platform tools could really help here.
See this question on server fault that details on how to move from Scrum For Team System V2 to Microsoft Visual Studio Scrum 1.0.
You would need to setup your own mappings to move from your templates to the target template, but the process is the same.
Please note witadmin.exe could help in some scenarios but TFS Integration Platform is your ultimate choice to achieve this task. There is a user voice item still pending. Please check this SO thread.
I think the best way to accomplish this is to create a new Team Project with "the new" process template and use the TFS Integration tool to migrate your existing WorkItems and choose create a new branch from Source Control, so you'll have new work Items (with the new workflow) and the source control history (as well). You'd even do this across versions of TFS!! (On the case interested on migrate TFS 2005/2008/2010)
Another way might be to use the WorkItem Templates, but I think this is more a kind-of visual style (I've not much experience) applied to the Work Item. To do so, just right click on your project, import the WITDefinition and apply the template by selecting Apply template on desired WorkITems.
Related
I have problem that is all my team members are altering the Sps and functions and
some conflicts occurred through the development
is there anyway or tool to store and get all version of them ?
the problem is before releasing the new version, i don't want a tool to compare difference between two databases like what Red gate SQL_Compare
thanks in advance
You may make use of the features in Visual Studio and TFS(or any other source control mechanisms). All that you need to do is to
Create a SQLServer DB Project in Visual studio and configure it to
your desired database.
Bind the project to a source control (TFS,
SVN etc.,)
Every time you have a change in DB, you can just compare the changes using .scmp file and click update.
You may refer this post for more information:
http://candordeveloper.com/2013/01/08/creating-a-sql-server-database-project-in-visual-studio-2012/
I am working on a team that have a number of developers working with SQL Server, developing stored procedures, functions etc.
I would like a consistent layout between the SQL, same header with a copyright etc. SO I need a standard template for the SQL. I know in Visual Studio it is possible to share templates.
How can I generate such a template for SQL Server Management Studio that I can share between developers?
This is how I do it:
the physical location of my template is in(Win7 SQL Server Management Studio 2012):
C:\Users\ys\AppData\Roaming\Microsoft\SQL Server Management Studio\11.0\Templates\Sql
I created my own folder in it (00_Mine)
Created a git repository
Asked other devs to pull from it.
In SQL Server Management Studio, press Ctrl-Alt-T or go to Menu, View, Template Explorer
It will list all the templates. However, from SSMS, there is no easy way to add templates to it by drag and drop, you can create new ones and put them into a folder, such as _WORK_.
The templates live physically in (for 2008 R2): C:\Program Files (x86)\Microsoft SQL Server\100\Tools\Binn\VSShell\Common7\IDE\SqlWorkbenchProjectItems\Sql, so you can simply drop files and folders in there or push out to team members using group policy. The templates are sorted alphabetically, hence the suggestion for _WORK_ above. Note: A restart of SSMS is required to pick up Template Folder changes.
Here's an article: Using SQL Server Templates
Question to users of template functionality: do you think it will be helpful if you had a possibility to have placeholders for data like: Current database, Current User, Date/Time (something else ?), so, when you open the template these placeholders would be replaced by appropriate values. I develop an add-in and had this idea a time ago, but I do not know if someone really needs it.
This might be a better question for https://sharepoint.stackexchange.com/, but since i am using TFS there may be differences, i am not sure.
I need to create a dashboard for a couple users that outlines our current sprint queries. They only need to see kind of the same hierarchy we would see if viewing a tree view in Visual Studio's Team Explorer (when running a tree query).
There are Sharepoint 2010 Dashboards.
Referenced here
Edit: Sharepoint 2010 configuration for compatibility explained here will be needed I guess.
I enjoy using SQL Server Management Studio for change and updating my database. Its easier, faster, and safer than writing changes myself.
I was looking into using some sort of version control for databases and read about using a SQL Server Database Project in Visual Studio 2010.
I scripted out an existing database and imported it into a new SQL Server Database Project. Now, from what I can tell, there is no GUI to edit the database; I can't add columns, change datatypes, or edit existing data without scripting it myself. For instance, in SQL Server Management Studio I can right click on a table-name and select "Design" and then add/edit columns, change datatypes, etc from there.
While Visual Studio's Database Projects has some features SQL Management Studio does not have I don't think I can live without a "table designer".
Is there a table designer built into VS's Database Project I'm just not seeing?
No, there's no table designer.
If you're starting to think about version controlling your database, you ought also to be thinking about writing actual SQL to implement your database objects. That's the route that the Database Projects force you down. If you can't write the SQL for your database changes, how are you going to be able to review and appreciate a diff between how a table was 6 months ago, and how it currently is in your project?
I've been using VS2008 Database Projects for about 10 months now for our version control. Every now and then I do still use the table designer, it is a quick and easy tool. I believe the majority of your question centers around workflow as this is what I found to be the most challenging part about development in a version controlled environment. I would recommend continuing to design your objects in Management Studio or however you're comfortable and then do a create script and import that script into your Database project. There are some quirks when doing this, you'll need to always script the create statement even if you're performing an alter in your environment. As well you'll need to remove any USE statements for your database as the context in which you're importing your scripts will always be in the project you're importing to.
We have found that a successful workflow for us to facilitate code deployment is to have a production branch which is branched to a Main (development branch) and then to test. All new development is done in Main and merged by changeset to each other environment as required.
You can import your scripts from your development environment by right clicking in the solution and clicking import scripts. I recommend that you check all the options to overwrite objects that exist, import extended properties and import permissions.
After changing your DB schema using SSMS's GUI tool, you can use Database project's Schema Compare tool to update your project files (set the source to be your database and target to be your project). This way you can keep using GUI tool to manage the schema and the database project will manage the versioning.
There is no visual table designer in Visual Studio 2010 Database Project. But, concerning version control for databases, there is a workaround - you can use SQL Server Management Studio together with Red Gate's SQL Source Control. It costs some money but definitely is worth it.
I have a solution that contains multiple reporting projects (one per target deployment folder - I think this is the only way to achieve this effect, at least until I abandon Visual Studio for report deployment).
I want to specify my data source information "once and only once" for all these reports.
So far, I have created a separate reporting project that contains my shared data source. If I deploy things to a reporting server in the right order and offer sufficient prayers to appropriate gods, the reports seem to link up to the shared data source there and run (at least via the Report Manager in IE).
When I am developing a report, though, I can no longer "Preview" to try it out locally - I now must deploy it to a report server to try running it. This is a hassle.
Is my only recourse to add a whole bunch of copies of a data source (pointing at my development database), one in each project, set those not to deploy off my machine, and (probably) exclude them from source control?
A technique (dirty trick?) I am playing with now is to copy my data source (.rds) into each project, close Visual Studio, then in the underlying files/folders:
Delete the copied .rds from my report projects (leaving only the one copy in my Data Sources project)
In each report project's project file (Foo.rptproj), change the text of the Project.DataSources.ProjectItem.FullPath element from My Shared Data Source.rds to ..\Data Sources\My Shared Data Source.rds
This way all reporting projects reference the same underlying file on the filesystem, so they share a single data source definition, but each project also kind of has a "local" shared data source, so Visual Studio is kept happy.
Regarding source control: there is still only one copy of the .rds checked in, so we're not polluting the code base with lots of icky duplicates; the changes to the .rptproj files can be checked in, so we're not forcing developers into unnatural source-control gymnastics (selective partial commits etc.) to maintain a sane master copy.
Each reporting project will try to deploy this data source, though I've forbidden the overwriting of existing data sources on the server, so it's not too big a deal . . . and I suppose if I intended to overwrite the server's data source definition, it wouldn't really matter whether I overwrote it once or ten times with the same .rds.
Disclaimer: this is still an experiment. I don't have experience using this technique in practice yet, so I can't go so far as to actually recommend it.
Woody,
What we have tended to do is:
On the server have a folder called "DataSources", which is hidden from the users. In there will be all of the data sources.
For each reporting project in VS there will be a folder, also called "DataSources", but this time it will only contain the data source for this report.
As long as the folder structure is the same (i.e. report and data source have the same corresponding folder level on server and in VS) this seems to work for us.