There are always been some deprecated extensions/tasks in the build task list.
Microsoft only add a tag with this kind of task, did it just mean :" we recommend that you do not use this task; it's deprecated"
It's beyond me, if the task is deprecated, why Microsoft not simply move it?
I have noticed some task have different version, will this deprecated task version updated in the feature?
Could I directly deleted this annoying deprecated task?
We’re not planning any feature updates, bug fixes, or support for the deprecated features.
Take a look at this:
We consider that a certain task is deprecated only when the latest
version of that task is marked as deprecated.
When the user searches for deprecated tasks, we push these tasks to
the end and group them under a collapsible section that's collapsed by
default.
If a definition is already using a deprecated task, we would show a
deprecated task badge on the task so that it's clear to the user that
the task is deprecated and hence is not currently being maintained,
there by encouraging them to make a switch to the replacement.
It is recommended to mention in the task description about the new
task that is going to replace the deprecated task.
Source Link: Deprecated Tasks
As for how long before it goes from deprecated to being removed?
Even though some task has been deprecated, but it will be available for a while.
We understand that moving existing definitions over will take some
time for our customers. As such, we have not determined a date for the
removal. We encourage that new definitions be created with new task
and also move existing definitions over as soon as it is possible for
you.
For delete a task, already answered here. Take care of this, if you need to reinstall a Task, the process is non-trivial.
Related
TFS 2017 u2. The task gallery for build/release definitions is crowded by tasks that are utterly irrelevant to our software shop. They're built-in, so removing the extension is not an option.
Any way to hide them?
CAVEAT I discourage you: if you need to reinstall a Task, the process is non-trivial.
This has already been answered at Remove custom installed build task on tfs
The idea is to use tfx build tasks delete. You need the GUID of the task: a quick way to get it is to look at the task.json file in the https://github.com/Microsoft/vsts-tasks repository.
Unfortunately, there is no way to hide the tasks. You could search the tasks you want to use, and I've submitted a UserVoice at website below, you can vote it:
https://visualstudio.uservoice.com/forums/330519-visual-studio-team-services/suggestions/33373423-hide-build-tasks
In tfs when automatic release occurs (each night) my team have to change their backlogitems asociated with this build to an state called 'ready for qa' next day, sometimes we forget it, if the build mark those backlogitems as 'ready for qa' when it's success it would be great. Is there a way to configure the automatic release to do that?
I don't believe there is any native way to do this, but the following extension Update Work Item in the VSTS marketplace should work for you.
After installing the extension, you will need to add a task to your Release Definition and configure it to suit your needs. Be sure to enable the "Allow Scripts to Access OAuth Token" setting in your release.
Note: there are some nuances in configuring this task to be sure to read all of the 'help' icons during initial configuration
Personally, I found using TFS Rest API as a good way of updating Work items. The Work items update TFS API is quite simple and easy to use
https://www.visualstudio.com/en-us/docs/integrate/api/wit/updates
The advantage of using it over build task is that you can run and test it locally and is easier to update and maintain
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
What is a version control system? How is Git useful?
I am new to Ruby on Rails platform, and so this may sound a little naive.
Why and when do we store our work in a version control system like git?
I mean what is the advantage of it ! Can't we just keep it in our local machine ?
Advantages for using git/source control:
For yourself
Remembering what you have coded and when you did it
Being able to compare what you did to previous work
Allow you to work on something experimental, and if it doesn't work switch it back to where it was before
Working with a team
It makes working with others easier - you can work on the same file at the same time and really easily combine your changes.
It will allow you to work in multiple locations and easily have the most recent code
It will help in deploying your code to a server
Git workflow for teams
Git branching model
When to store or commit your work:
You want to do this each time you finish on a particular "idea" or piece of work you are working on. This means you can have a useful commit message and can go back im time to that feature you just wrote or that bug that you just fixed.
How often and when to commit
Reasons for using Git over other source control
Its fast (switching branches is really fast and you have a local copy, so you dont have to communicate to a server for a lot of things unless you want to push or pull changes to the server)
Yes, this seems quite naive, but every question is worth asking!
First of all, using a SCM (software configuration manager) will greatly help you in a number of scenarios:
trying out experimental features without touching the main code
developing several independent ideas at the same time
recovering from failed changes, whenever they are complex and include changes in multiple files.
tracking the exact code used in a specific release, to fix a reported bug.
This doesn't even start to touch the infinite amount of work you'd have if working in a team without SCM.
And using a SCM doesn't involve network, git and any other distributed SCM is equally valid for local development, as the repository is all in your computer. You just don't pull and push.
The choice is not whether to store code in version control versus storing it on your local machine. In fact, unlike other version control systems (like Subversion, known also as svn), Git does not need a server to run.
Version control makes it easy to understand what changes were made, view and restore older versions of files, and even import changes from one version to another.
RETRIEVAL: Imagine you are working on a project on your own. You delete an old file you don't think you need anymore. A week later, you realize that the file was very important. If you use version control, you can see what the file looked like just before you deleted it, and restore it as if it were never deleted. Also, most changes committed to version control contain messages; if you join a team and the previous developer used version control (with good commit messages) you can get an easier context for when changes were made and why.
MULTIPLE RELEASES (BRANCHES): Now imagine that your software is version 1.0. You're busy working on version 2.0, but someone files a bug. What can you do? With version control, you can zoom back to version 1.0, make some changes, and then create version 1.0.1. Most version control platforms even let you apply the changes made in version 1.0.1 onto the work you're doing in version 2.0.
MULTIPLE FEATURES: Your software is so successful, you start releasing it weekly. However, not every feature is ready for release. First you start working on the widget feature, than you start working on the doodad feature. If you work on both of these at the same time, you may have two half-coded features in development at the same time, and nothing is working well enough to release. With version control, once one of the features is done, you can merge it into the "main" release as if you wrote it in one day.
COLLABORATION: Finally, now imagine that you're in a team of five or six developers all working on the same code. Naturally, you don't want to email zip files of code back and forth, especially when every developer is working on a separate feature. With version control, you can have a single history, to which all of your developers write and read.
Naturally, some of the above can be done by keeping multiple copies of the same files in different adjacent directories. The benefit of version control software is that it can handle much of the work for you while avoiding duplicating the same file over and over on your disk.
Long winded--sorry--but hope that helps!
Advantages of using git:
Code will be safe in remote repo, even if the local project crashes
You can try out new things without worrying about previous works as they can retrieved
The code can accessed from anywhere in the world
When working in team, all the work will be stored in a single place so that it will be accessible to everybody in your team
Each and every change can be tracked easily, who did it and when they did it
Deployment of application will more easier
You can have multiple versions/branches so that it will be easy for you to identify the new features added to the application in every version
you see #arulmr, #kieran-andrews, #Jeff and #rewritten that post many advantages but still if you want learn more in details you can see below links
1) http://git-scm.com/book/ch8-1.html
2) http://www-oss.fnal.gov/~mengel/git_vs_subversion.html.bak
3) https://git.wiki.kernel.org/index.php/GitSvnComparison
4) http://www.wikivs.com/wiki/Git_vs_Subversion #History, Architecture, Licensing, Performance, Features of git and svn
now the difference between git and subversion
1) http://boxysystems.com/index.php/5-fundamental-differences-between-git-svn/
I have a Mantis bug tracker installed that we use for all of our products. One product goes through a rapid development cycle and each new build gets a new version number (the build number is incremented). Since our QA has to report all bugs they found for the build that introduced the bug, we also have to add a new version number to Mantis every time a new build is made. Because of this, the list of version numbers under Manage->Manage Projects->Project name is now very long.
I just tried to delete one of the very old version numbers but that removes that number from all issues that referred to it. (Makes sense from a DB design point-of-view.)
Is there a way to shorten the version list without affecting the issues? The very old version number we have will never be used again but I want the old issues intact. I did a bunch of Google searches but I keep getting flooded with unrelated results.
Did you try to set the obsolete attribute of version ?
As said in the admin guide :
Each project can have several versions, which are marked with attributes like released and obsolete.
and :
Once a version is marked as obsolete, it is now longer included in the change log.
See also these issues :
Obsolete versions not selectable as filter in `View Issues'
Versions marked as obsolete appear on change log page
If I understand you properly, what you'd like is a way to filter the versions displayed in the Manage Projects page.
This cannot be done in current version of MantisBT (1.2.14), and would require a change in the code. I suggest you open a feature request on our tracker. If you end up implementing the feature, then submit it as a pull request on our Github repository.
Is there a posible to get previous version of code in TFS Build script?
I need to get curren version of config file and version from previous check-in, compare them, check if some files in other folders have the same changes and save the results to log.
We have a similar situation, where we need to get data from a file before getting the latest version. I don't know how much of this is applicable to you, but here's how we do it:
Since we're using CruiseControl.Net for build management, we turn off the autogetsource control in our configurations.
We have built a MSBuild Custom Task (if it's a fairly simple task, you can do it in-line) that retrieves the information we require prior to Get Latest.
"Manually" perform the tf get operation (as an MSBuild task)
Re-run our custom task to retrieve the new information, and act upon differences (for example, use as condition for later tasks)
Both in our case and yours I guess that a method for retrieving/comparing with the "previous" version of an item would have been preferred, but I was stumped there; I couldn't find any relatively easy way to retrieve the previous change set for an item. If anyone has any good ideas there, I'd like to hear these as well :).