We have an on-premises TFS instance in our company, and we notice that the sonarqube extension is getting updated automatically. https://github.com/SonarSource/sonar-scanner-vsts
We are worried to have it updated automatically in our production environments, is it really the way it was designed to work? Is there a way to do the updates manually instead or a continuous delivery model?
Yes, this is an expected behavior. In TFS 2017 we added a feature to automatically check for updated external extensions once a day and upgrade them. No way to stop this unless you use a prior version of TFS.
If the account running the TFS Services does not have access to the internet then the jobs will just be marked as failed. They will still attempt to update everyday. To update, you then just have to download the VSIX from the Marketplace and upload it to your local gallery to update the extensions
Related
My company is considering upgrading our on prem TFS 2017 update 3 to the latest Azure DevOps Server (notably, the on prem variety).
During discussions about that possibility, one key stakeholder claimed that if you upgrade, all of your build and release pipelines would have to be rebuilt from scratch. We have a healthy number of build and release definitions in TFS 2017.
I have looked for the answer in the Microsoft documentation about what exactly gets upgraded, but unfortunately I can't get the level of granularity which would prove or disprove the above claim. On the surface it would seem like a horrible upgrade story if it were true. But I also understand that designs and architectures change and upgrades aren't always possible.
Could somebody let me know whether the build and release pipelines can survive the upgrade more or less unscathed? Knowing this would be a valuable data point as we work toward a decision.
Thanks in advance!
The vNext build definitions and the release pipeline I would expect would be pretty lift and shift. Depending on the tasks that you have defined, they might no longer be supported or there might be new versions. The UI will let you know that new versions are available.
A lot of the new focus is building out the features for the YAML build definitions. If you want to leverage those, you'd have to do a lot more rework of converting those vNext tasks into YAML. But converting is not really a hard requirement.
You mentioned that you aren't using the XAML build definitions, but if you happened to be using them, I would image that is where a lot of the rework comes in. Having done that in the past, I can say it is a pain if you have to do it.
all of your build and release pipelines would have to be rebuilt from scratch.
I've tested it and it won't lose any data after upgrading. We should use scheduled backups to ensure that we always have backups in place in case something goes wrong.
we can use that new hardware to do a dry run first, and then we will wipe everything clean and use it again for the production upgrade.
For our dry run, the steps for our upgrade will be:
Copy recent database backups to our new SQL instance.
Install TFS 2015 on our new application tier.
Use scheduled backups to restore the database backups.
Run through the upgrade wizard, being sure to use a service account which does not have any permissions in our production environment. See Protecting production in the dry run in pre-production document for more information.
Optionally configure new features which require changes to our existing projects.
The production upgrade steps will be quite similar. There the steps will be:
Take the production server offline using TFSServiceControl's quiesce command. The goal here is to ensure that the backups we use to move to our new hardware are complete and we don't lose any user data.
Take new backups of each database.
Copy the backups to our new SQL instance.
Install TFS 2015 on our new application tier.
Use the scheduled backups wizard to restore the database backups.
Run through the upgrade wizard, using our desired production service account.
Optionally configure new features which require changes to our existing projects.
You can refer to this doc for more details.
we have just upgraded to TFS 2017 from 2013. We had a custom plugin that ran when we changed the build quality. Since the upgrade it doesn't fire. we have tried changing the required DLLs to use the The 2017 client dlls. but the build quality handler does not trigger the plugin. it uses the Microsoft.TeamFoundation.Framework.Server.ISubscriber interface. We do not get any exceptions as well on the tfs server.
The ISubscriber implementation needs to be recompiled against the TFS 2017 Server as well as Client object model.
And it's important to understand that the new build infrastructure (the non-xaml builds) likely trigger a different set of notifications. At least they're not queryable with the old Client Object Model IBuildServer, you need to use the new REST API.
Without knowing more about your setup (what type of builds, the exact versions of the object model you're binding against, what permissions the TFS Service user has) it's hard to tell where this is going wrong. We have a troubleshooting guide for the TFS Aggregator (https://github.com/tfsaggregator/tfsaggregator/wiki/Troubleshooting) which is also a ISubscriber plugin, it may help you debug your setup.
It appears a fair number of release management deployment tasks and templates are not in TFS 2015 on premise right now, and I'm trying to figure out if this is by design or if my installation has problems. For instance, I do not have a sql deployment task available to me. I haven't been able to find confirmation one way or the other, so does the on premise version just not have these tasks?
be aware that VSTS development is always some months ahead of on-premise TFS. Especially release management is quite new and many enhancments and tasks will probably find it's way to TFS. Either directly, as extension or you can create custom tasks by yourself.
As seen here:
https://github.com/Microsoft/vsts-tasks/issues/1674 it's a very young step and all you need to get it work on your local TFS is on github:
https://github.com/Microsoft/vsts-tasks/tree/master/Tasks/SqlServerDacpacDeployment
This is by designed. It seems you are using some Extensions. You can find this in available extensions on the right top of the web portal.
Then you can find those tasks in below page and just need manually install the tasks.
DacPac deployments are part of the extention "IIS Web App Deployment Using WinRM"
https://marketplace.visualstudio.com/items?itemName=ms-vscs-rm.iiswebapp
Download and install it on your TFS server. You need to have Windows Remote Management enabled on your database servers for it to work.
I found this web site useful in getting it setup on the database server
http://www.hurryupandwait.io/blog/understanding-and-troubleshooting-winrm-connection-and-authentication-a-thrill-seekers-guide-to-adventure
We are in the process of migrating/upgrading our TFS2010 to TFS2013, new infrastructure.
We are following the step by step upgrade guide.
Regarding workspaces, do the developers need to remove all the local mapping to the old TFS instance before the upgrade? If Yes, we can ask them to remove.
However is there any way to find out whether the developers have removed all their local workspaces from TFSadmin point of view rather than asking the developers to say whether they have removed or not?
Best Regards
However is there any way to find out whether the developers have
removed all their local workspaces from TFSadmin point of view rather
than asking the developers to say whether they have removed or not?
Installing TFS Sidekicks will allow you to see what workspaces exist for a particular User / Machine, it will also allow you to delete workspaces and to remove file locks.
It is not required when doing an upgrade to have developers remove workspaces. After the upgrade Visual Studio will automatically match it all up correctly.
Note: Make sure that you only do this for production. If you are doing a trial migration you MUST change the server ID to prevent VS getting confused!
http://msdn.microsoft.com/en-us/library/vstudio/ee349259(v=vs.110).aspx
I'm working in a project and I'm trying to optimize testing process so, when I execute a test case and I found a bug, I would like to associate this bug to the current build.
The builds are created automatically but when I try to select the built in the droplist there are not builds to select, so... How can I do it to get all the builds that I've made automatically?
Maybe is there any issue with Global List?
Im using VS 2010 and I have installed TFS 2010 Power Tools.
Thanks in advance!!
The global list is normally updated by an event subscription on the server that handles the BuildCompleted event. On your TFS server, there should be an executable named BisSubscribe.exe. You can use that to verify or fix the subscription. For more details, check out Jason Prickett's blog post on How to filter the Build Completion Event.