This question is a bit round about, but I'll get to that in a minute. When someone changes the build's quality in TFS (we're on 2005) what exactly happens? Does this affect changesets or workitems, notifications??
Now the reason I ask: I want to be able to generate a changeset list between builds. As such selecting a build on Jan 1 and comparing it to a build on March 29, I want all the changesets between those builds. Perhaps there is another way to do this but I do think the build is the starting point.
Out of the box, it's just meta data about the build. The intent being you can use it in your development process to indicate when a build has progressed through certain quality gates.
It should be noted that the open source TFSDeployer project relies on the build quality as a trigger mechanism to run deployments scripts.
In TFS 2012, you can set a quality threshold on builds to say which ones can be used by Microsoft Test Manager for testing.
In MTM, in the Testing Center, under the Plan tab, under the Properties subtab, there is a section called Builds. You set a quality threshold with "Filter for builds" and then any builds that conform to the filter will show up when you click Modify under the "Build in use" line.
On a side note, I have found some interesting info here about automatically updating build quality through XAML.
I think it is just a notes field. I see it show up on some reports, but nothing else of value.
Related
We are using Sonarqube 8.0 and TFS together with gated checkins. So when I check in a version of the code that makes the quality gate red, we break the build and the checkin gets rejected. But if I check in the exact same code again, sonarqube only analyses the new code and therefore the gate is green again, as there is no difference to the last analysis, which was red. So we where thinking to make the "New Code Period" the last green analysis, but this does not seem possible. I can only choose "Previous" "Periods of days" and "Specific". To me this does not make all too much sense, as I only want to see what is changing to my current checkin. Maybe we have to analyse the master branch and only set the analysis to check versus a specific version of the master branch, but that seems like a lot of work to always select a new version when we merge to master.
I know the analysis works better with pull requests to master from private projects, but we do not have git here, so this is no option right now.
Is there a good way to keep our dev branches clean with sonarqube? Right now it feels a little useless in combination with TFS and a single DEV branch…
I don't understand what Promoted build really is and how it works. Can someone please explain to me like to a 10 years old kid. If you can provide some sample examples would help me a lot.
Thanks
In a typical software developing organization with CI system, there are 10's or 100's of continuous builds daily. Only one of those builds (usually the latest stable) is selected and "promoted" to be a Release Candidate (RC), which goes to the next quality gate - usually the QA department. Then, they select one of those RC's (others are dropped) and again, "promote" it to the next level - either to staging environment, validation etc. Then, finally... one of these builds is again "promoted" to be an official release.
Why is that important?
Visibility: You would want to distinguish many "regular", continuous builds from few, selected "RC" builds.
Retention: If you commit often (which is the best practice), you will likely get lot of daily builds, and would like to implement a retention policy (e.g. only keep last 100 builds or only builds from the last 7 days). You will then want to make sure promoted builds (RCs) are locked against retention. This is mostly important if you deploy binaries to customers, and may need the exact binary to reproduce an escaping bug in the future (though you still have the source code in the repository, I've seen cases where escaping bugs relate to the build process rather than the source code - due to rapid changes to the build process, or time-of-build sensitive data like digital signatures).
Permissions: you may want to prevent access to builds with "half baked" features from non-developers.
Binary Repositories: you may want to publish only meaningful builds to an external binary repository.
Builds in Jenkins can be "promoted" either manually or automatically, using plugins like Promoted Builds Plugin. You can also create your entire "promotion" workflow using pipeline scripts. Here's an example:
a "Continuous" job that polls SCM and builds on every change. It has a retention policy to keep only the last 50 builds. Access is restricted only to developers;
a "Release Candidates" job that copies artifacts from a manually selected build (using parameters). Access is allowed to QA testers;
a "Releases" jobs that copies artifacts from a manually selected RC. Access is allowed to the entire organization. Binaries are released to external/public repository.
I hope this answers your question :-)
We set up TFS 2013 recently and tried to set up gated check-in. In our experiment, it correctly failed the build and rejected the bad check-in. However, both the build notification tray icon and the build tab on the TFS web access show the failure, and it is this way for all users. This will make everyone think "the" build is broken when it's just one person's "gate." It will skew metrics, too.
A) Why would this be the default behavior? It seems very counter-productive and counter-intuitive. [Or maybe this isn't the default behavior and our setup is hosed?]
B) Is there a configuration for the build tab where a rejected gated check-in/build is visible only to the person who broke it?
C) How can we make the build notifier tool ignore gated failures?
a) This is a public build. Why should it be failing. If the gated build is failing it shows a lack of care by the developers. Are they checking in any old thing? Are they running their unit tests first? It really sounds like you have a quality issue there.
That is why the gated-builds are still public builds.
b) no - Anyone can however send a Private build to the build server if they think that there may be an issue that they can't catch locally..
c) Each user can uncheck the monitoring of the gated build. I would however suggest that they should concentrate on not failing the build however rather than sweeping it under the carpet...
A filed build, even a gated one, should be the exception and not the rule...
MrHinsh answered my question from a largely philosophical standpoint, and that led me to this article:
[http://adamstephensen.com/2012/11/01/gated-checkins-mask-dysfunction/]
I agree in principle with the article. However, because we are attacking agile processes in baby steps, we still want this extra safety check for the time being.
Below isn't the exact solution we wanted, but it is a hybrid of the approach in the article and my original question. It doesn't force gated check-ins, but it allows them to be done, giving risky check-ins a safety net. Code quality beyond build-ability will be addressed with other mechanisms outside the scope of this question.
The compromise solution is that "vanilla" changes would be checked in normally (after local testing, of course), and then the CI build would kick in. Fixing broken builds would be high priority to be addressed immediately.
But anything out of the ordinary (configuration changes, referencing new/different external dependencies, or just anything a developer is unsure of) would use a private gated check-in, but not on the main build, because we don't want everyone to be tricked into thinking the build is broken upon rejections. This build definition is a clone of the main build definition, but with the addition that upon successful check-in, it chains a build of the main build definition using this:
[How to chain TFS builds?
While the main build is redundant in most cases (race conditions may apply), it solves the immediate need.
Currently we are using StarTeam to perform the build as well as versioning. we planned to migrate startteam to TFS2010. We have some script for perform the build. i wanted to change this script according to my requirement. i gone through the TFS but i had lot more confusion.
in StarTeam, we will get a files from "Ready to Build" label and perform the build. In TFS, how we are going to get a files from TFS? What concept should i use to get a files and perform the build? i have gone through the lot of commands like get, check-in, checkout etc..
If we use "tf get" command, we can get all the files from TFS but i have a clarification on that. shall i get all the files from TFS for every build? i hope, this is unnecessary headache.. correct me if i am wrong..
how we perform the build in TFS? i have read some types of build such as manual, gatedcheckin, Continuous Integration and schedule.
Is there any relationship between branch and build activities?
In TFS, What is the meaning of Workspace?
As said, many questions in one. Hope this helps along the way:
A workspace is a mapping between the server and a local storage,
similar to checkout in Subversion, view in ClearCase, etc.
"TF get" normally only fetches those files that have changed since
last update. You can force it to fetch everything - and sometimes
have to - but its not normally done.
Team Build is the recommended system to build with when using TFS. It can take some time to get into (Windows Workflow-based), but is quite powerful. There are default process definitions that set up the most common actions for you.
By default, you can't control whether to build by setting a certain label, but you can define that only this label should be used when builds are triggered. Labels in TFS work a little differently compared to other VCS, though, so maybe there's an 'opportunity' to re-think your build process along the way. If you're set on using a label as before, you'll need to build a Custom build activity.
Does TFS offer a way to save, track, and later redeploy builds by build number, or can you only deploy .dlls compiled from the current codebase? I'm looking for functionality similar to what you find in Changeman DS.
Yes. Every build definition in Team Build has a "retention policy" that defines how many historical builds should be kept, depending on certain criteria. You can also mark individual builds as "keep indefinitely." Kind of like a Tivo...
Example walkthru with screenshots: http://blogs.msdn.com/buckh/archive/2007/08/14/tfs-2008-a-basic-guide-to-team-build-2008.aspx
If you need to recover a build that has already been deleted from the drop share, you can do that too -- you'll just have to rebuild it. Simply queue up the build definition, but before you hit Go, type /p:GetVersion="XXX" in the text area at the bottom labeled "additional MSBuild arguments." XXX can be any versionspec, just like you'd use at the tf.exe command line. Examples might be "C12345" or "D1/10/2010" or "LsomeLabel".