Given a feature file I can generate step definitions in visual studio no problem. Are there any tools (e.g. visual studio plugins?) out there, which allow me to sync feature files and step definitions (just the step definition method signatures of course)?
We are also using speclog which is synced with tfs. Are there ways to synch tfs and speclog in terms of feature files (i.e. the original acceptance criteria in speclog)?
There's currently no support to update the step definition signature automatically. I guess what you're looking for is some kind of Gherkin/step definition refactoring tools.
One thing that might be useful though for what you want to accomplish is the step definition report, that lists unused/unbound steps: http://www.specflow.org/documentation/Reporting/
For syncing feature files from source control (e.g. TFSVC or Git) to SpecLog, you can link requirements to feature files like outlined here: https://github.com/techtalk/SpecLog-Resources/wiki/Gherkin-Attachments-For-Acceptance-Criteria
Related
situation:
we have multiple feature branches, one main branch;
one particular project has multiple XML files, key-value pairs for different languages;
only one person doing translation, not programmer, but an analyst;
we use feature branches to separate features and scope of testing; different QA is responsible for testing on different branch for different user story.
when a user story is done, we merge the feature branch up, and sync down to other sub branches
those language XML files are large, say, roughly a few hundred key-value pairs in each.
challenges:
challenges come when multiple feature branches need translation, and the translation changes are done in the same file, say Japanese;
QA occasionally files a translation bug fixed in another branch;
the analyst is confused which branch to work on;
very high chance when merging, one version overwrites another version; because when we merge from a branch, the default logic in TFS takes the newer version to overwrite it. Most of time it works fine, but in some cases it failed, which increases the complexity of merging.
of course those challenges are manageable.
But ideally, I really think those static files should belong to one place instead of feature branches, so all feature branches share the same translation pack.
I could use an internal nuget source to host the language files, but it will increase the work every time we make a small translation change.
or I could setup TFS to use relative path, but then I need to update build definition in the build server and make sure the local build can grab the correct file.
Is there any other recommendation?
Thanks
If you have any shared internal libraries then create NuGet packages should be a good way , and you can also create a vs solution just containing that library.
For XAML build, add a post build command to create the nuget package, or extend your tfs build template to do it (there's a number of templates out there that already do this).
For VNext build, there is a new VSTS Task called "NuGet Installer" this allows you to check in your NuGet.config file and specify the different package sources. Run this task before you run MSBuild. More details please refer: How to get TFS2015 Build (Build.vnext) and NuGet package restore to use custom package sources
Moreover, I think if your product or app haven't been published to user, the update changes of translation could not be so frequently. After all, just some translation and language packages. You could update it once or twice during an iteration.
We're using Team Foundation Service instead of a local TFS.
Our solution was created on Visual Studio 2012.
My problem is now that we want all assemblies to have the same version number (this part is already solved by using a CommonAssemblyInfo.cs that is linked into all projects).
The issue I'm facing right now is that we need the tfs changeset number at the last digit of the assembly version (e.g. 1.0.0.4711 where 4711 is the changeset number).
I've found several examples, but none of them worked for me.
And yes, I especially searched here on stackoverflow a lot.
I also have to admit that I've never looked into the MSBuild scripts...
Can anyone please give me a hint on how to accomplish this?
Is it for example possible to use the MSBuild Extension Pack on Team Foundation Service (not local TFS) and if, how to do that?
As always, time is my worst enemy...
Note that from 2010 Tfs employs Windows workflow for building the package the workflow calls msbuild for compiling the projects only - while its possible to pass changeset this way to msbuild its rather more hops.
Following deals with your problem, however the linked solution is more complex that needed:
Can assembly version been automatically updated with each TFS 2010 Build?
This is one of best series of tutorials on the custom build activities, the author is on stack as well i believe, one specificly about versioning
http://www.ewaldhofman.nl/post/2010/05/13/Customize-Team-Build-2010-e28093-Part-5-Increase-AssemblyVersion.aspx
In short you need a custom activity to run before compilation on source files, find all CommonAssemblyInfo.cs files, feed this list to your custom activity, it modifies the values inside with passed value of full version number or only the changeset and optionaly check in the change (probably not since your changeset will be out of sync then).
You can also take a look at https://tfsbuildextensions.codeplex.com/ set of activities there is TfsVersion activity among them, at the very least it will provide examples.
Functionality need for this should be available through Team Explorer and source control - The Custom activity assemblies and build templates usually are located in folder in your team project root - the location of this folder is defined for build controller you can change this through team explorer build section.
Changeset is available from value BuildDetail.SourceGetVersion, not sure if this was fixed/changed in 2012 however there were 2 issues about this value in 2010
Its doesnt respect GetVersion override in default build template - you will manualy need to update if override is used
When running latest build (no override) it will get the last changeset number from tfs - depending on your branches this may not be the same as 'last' changeset for the branch of build. You will either have to live with this, provide overrides for each build or implement activity that checks branch history for last changeset value and overrides it again.
It should be noted that GetVersion should be able to accept any sourcespec version - changeset, date, label etc. I havent played around with this enough to provide more details to you.
Colin Dembovsky wrote a great overview of doing version embedding using the new pre-build script setting in TFS 2013 build definitions.
The Changeset number is easily accessible within the pre-build process in the environment variable TF_BUILD_SOURCEGETVERSION. I was able to use this to embed the Changeset value in our binaries using a script based on Dembovsky's work above. (I used Perl, not powershell, so you probably don't want to see it ;-)
This approach doesn't require any changes to the build workflow which makes it a big win for me.
I've used Wintellect's solution - MSBuild-only, no TFS magic needed. I also added to the auto-generated CSharp file:
[assembly:AssemblyInformationalVersion("$(BuildNumber)")]
So I get the TFS build number.
I am pretty new to TFS but I have some experience with VSS. I like to know your opinions of what would be the best way of working with TFS in the following scenario:
We are a group of developers working on projects. All projects starts from a common base code. All projects are one man only, no code sharing until the project is done. A project can last from a few hours to several months, no code is merged until done. Any developer works simultaneously on more than one project, usually 7-10 projects at a time. Usually the projects only involve a small numbers of files that are changed/created (10-20) but rely on a large group of infrastructure files that change quite often. However, any change in infrastructure is not considered until the merge, so we don't get latest version from server until the final build.
An additional request is that, when merged, we’d like to use a 3 way merge tool. We use this approach in VSS, via a custom made application and it works very well. However this involves special file management, for example every file that has to be changed must have an original version saved somewhere that will be used as the “root” file for the 3 way merge process.
What do you think?
You should take a look at the Visual Studio TFS Branching Guide 2010. (direct download). In that package, there is a PowerPoint deck that walks you through a series of possible branching structures.
It sounds like you want either "Branch by project" or "Branch by developer" (since you only have one developer per project, these are effectively the same).
Regarding the 3-way merge tool, take a look at this list to see how to configure your favorite diff/merge tools.
We're currently setting up a number of builds in TFS2010 for our various projects/solutions.
We have a large number where the structure and paths, etc. are essentially the same, but one word may change (for example, using all Integration workspaces versus our Trunk workspaces).
In TFS2008, I would simply edit the XML directly and do some creative search and replace or some magic in textpad before saving the file. However, I do not see any immediate way of doing this in TFS2010 - so I'm stuck slogging through the build definition UI.
I know, in doing a SQL Trace, that all of this ends up as XML - so is there a way to directly access this XML for hand-editing vs. being forced to do all changes through the front-end?
Thanks!
Edit for additional clarity
I have the Power Tools installed, etc. and can clone my builds - but my editing options are still limited to the UI, so if I have a large number of workspace path changes I have to do them by hand (one at a time).
My goal is to be able to directly edit the XAML for a specific build definition so I can do a clone, open the XAML, and then do a search/replace in bulk.
Download and install the Team Foundation Server Power Tools. You can also get them through the Visual Studio Extension Gallery. After installing, you can right click on a Build Definition in Team Explorer and select the Clone Build Definition command (added by the Power Tools installation) to make a copy of an existing build definition. Then you can tweak it appropriately for another branch, etc.
The following tool (VS Addin) will satisfy your requirement>
Community TFS Build Manager
http://visualstudiogallery.msdn.microsoft.com/16bafc63-0f20-4cc3-8b67-4e25d150102c
The build definitions are all .xaml files now - they're WF4 workflows, and they're XML files.
Jim Lamb is right. The build templates are .xaml files now. The definitions are accessed through web services.
I'm about to experiment with a quick HTML form posting to /tfs/_tfs_resources/Build/V3.0/BuildService.asmx/QueryBuildDefinitionsByUri. I noticed when I clicked the build definition in Team Explorer that it has an associated URI: vstfs:///Build/Definition/2. Stay tuned.
TFS 2008 and Common Libraries
I have created a Team Project called "Common Library" that will host code used in numerous different Team Projects throughout TFS. For sake of argument, lets say we have 2 distinct Librarys under the "Common Library" Team Projects, MailProject and LoggingProject. Other projects throughout TFS will be using the binary representation of these projects via branching and not the actual source code.
What is the best way to set up the folder structure for this Team Project? Do I add the project to the "Common Library" and simply "include" the bin/release folder as part of the project?
I have seen some examples of people creating a seperate "Deploy" folder. I assume this is synonamous with the bin/release folder?
We do not want the source code available in other solutions.
Currently, each project has the dll included in the project. Using a mailing module as an example, many projects need the ability to mail. The common module is very stable and mostly static.
However, what if there is a change in the mail module. It seems there would be a better way, than to check out each project and update the dll. Is it possible to allow TFS to grab the latest mail module any time a 'get latest' is called? Either explicitly or implicitly.
Unless you really require the source code for the libraries to be available in the other solutions my advice would be to include the binaries for the libraries in the projects that would use them not really having any explicit link between the two in TFS. Custom labelling of the library builds could be helpful to easily return and rebuild any chosen version of the shared libraries.
If the shared libraries require different versions for different projects then the obvious solution would to create a separate branch for every version of the libraries that need to be customised to a particular project.
TFS does not have a concept similar to SVN's 'externals' though - so if you include a branch from the shared libraries in a project and than branch that project it is very difficult to propagate changes correctly.
I suppose you could also use the Get task in the build and get the latest version of DDLs into the current project from another one, but verify if you can point of Workspace of another project (I have not tired it and MSDN is somewhat vague here). You might need to have a separate workspace for the shared project.
Yet another alternative would be to publish the DLLs for common components to a known location on every build of the shared libs and for individual builds to get whatever version is available from that common location (network share) even via the Copy task. This is simplistic and may cause problems with versioning of the common components but should work well enough in simple case.