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
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.
I've recently developed custom build runners (plugins) to TeamCity and Jenkins. The plugins enable the users to start automated load tests as part of the build process.
To give you some idea here's the Jenkins plugin page with a lot of description:
https://wiki.jenkins-ci.org/display/JENKINS/Apica+Loadtest+Plugin
Here are a couple of screenshots of the TeamCity plugin:
The setup GUI: https://i.imgsafe.org/5221a01.png
Build log: https://i.imgsafe.org/c93f7f9.png
Custom tab with load test summary: https://i.imgsafe.org/f5b6937.png
Setup validation example: https://i.imgsafe.org/52cc9a2.png
These Continuous Integration frameworks allow a high level of customisation for plugin development: the UI, the output, client and server code etc. can all be tailored.
I've received a question whether we can develop a similar build runner for MS Team Foundation Build Service. I've completely new to TFS, I've never used it for anything. I've read through a couple of tutorials on how to install and set up TFS but there seems to be very little material available regarding custom build runners. The closest I've got are the following pages:
https://msdn.microsoft.com/en-us/library/bb130146.aspx
http://blogs.msdn.com/b/jimlamb/archive/2010/02/12/how-to-create-a-custom-workflow-activity-for-tfs-build-2010.aspx
However, they don't provide any example on GUI extensions, validation, customisation etc.
Therefore I'd like to get the opinion of experienced TFS users before we get any more serious with the framework:
is it possible to develop plugins for TFS build?
what are the limitations? E.g. can I build a custom GUI with custom client/server actions?
can I include custom pages, show graphs etc?
Any advice is welcome.
Thanks for your help,
Andras
When it comes to TFS Build, you first need to know that there are two build systems: XAML Build and a new, now default, build system.
XAML Builds are based on Windows Workflow Foundation. You can create custom activities and add these to a Build Definition Template. XAML Build only run on Windows and extending them is not very easy.
The new Build system is based on Node, runs cross-platform and is very easily extendable. Microsoft has open sourced all the tasks they have for TFS Build (see GitHub for the repository).
Targeting the new build system means that you support on-premises installations of TFS 2015 and the cloud hosted version of TFS: Visual Studio Team Services (see visualstudio.com for more info).
The easiest way to get started is by creating a new VSTS account (free!), adding some code and running a build. If you have that working, you can start exploring the existing build tasks and learn what's possible. You can then easily create your own task and start experimenting.
One thing that might be of interest to you is that TFS/VSTS already support load testing. You can run a very simple load test with a couple of mouse clicks or configure more complex Web Tests and use these in TFS in combination with Application Insights. I'm not sure if that's what your customers are looking for but it's worth checking out (see Cloud-based Load Testing for more information)
Like many other out there I had the fun task of upgrading or TFS 2008 server to a brand-new TFS 2013 install.
The good news -> this has been done and documented. The bad news -> you have to migrate to TFS 2012 and then Migrate from 2012 to 2013.
All things said it mostly went fairly smooth. I cannot really complain. There is one hitch, however. Or plan was to use an intermediate server (SQLTFS01) for the TFS and SQL Server 2012 install and then most everything onto our destination server for 2013 (SQL008). Then we were to take SQLTFS01 offline and re purpose that machine.
In the end there was a missed step. It seems that our final install of TFS2013 is still pointed to SQLTFS01 for the reporting services components. See here:
Attempts to disable the reporting and analysis services portion of the server are all failing because even in order to disable the tool, it tries to connect to the existing tool.
Question: How can we disable this feature or redirect this stuff? Can we do it though setting files that I am not aware of?
Thanks,
Tom
I would recommend that you "unconfigure" your application tier by running "tfsconfig setup /uninstall:all". This will nit touch any of your data but will reset your app tier to the state before you ran the configuration.
You can then follow the steps in the "move to new hardware" documentation so that you don't miss any of the steps:
http://msdn.microsoft.com/en-us/library/ms404869.aspx
If you start from after "restore databases" step you should be good.
I just started with Team Foundation server and read different tutorials then tried it on default cloud server. As there is mentioned that we can only use team foundation server FREE up to 5 members. That is why I want to setup TFS on my server.
Please suggest me should I go for it ?
Is there any advantages of using TFS on cloud instead using it on my own local server?
Also is there any GOOD tutorial to setup TFS on my machine and enable it for my other team members remotely ? ( I am following this ) .
Zauk
TF Service is a nice way to get up and running quickly, without worrying about infrastructure, backups, etc. What you lose is some customization, lab management, and SSRS reporting, more info:
So which one to use is depending on your situation.
For tutorial on Install TFS
Just take a look on my 2 Guides about installing TFS 2012 and 2010, you will find step-by-step tutorial that explain to you exactly what you should do and how to verify every steps before moving to the next one, they have videos and documents with every detail steps needed.
I recommended to have a look on the whole sections because sometimes service accounts used for configuring different TFS components are very important.
TFS 2012 Guide
TFS 2010 Guide
This seems like it should be obvious so maybe I am not understanding something. I have TFS setup. My web apps code is in source control. I can check-in/out and create builds but I don't quite understand what the recommended method for publishing the code to the production environment is? I was looking for something like "publish release to web server" but can't find anything. I think my larger problem is that I can't find a good work-flow diagram for how a team is supposed to move from editing code to testing and then to deploying to the production servers all within the TFS system. If anyone has any thoughts or links to good walkthroughs on publishing a website from within TFS that would be fantastic.
For the workflow I would suggest the code promotion model.
Within TFS you have the idea of build quality. SO when you initially check code in the build will kick off with a quality of say "ready for test" if the build passes the testers can decide when they want to take a build for testing, when they have tested a build they can mark it as "ready for deployment", you can then use that realeas to deploy.
Unless things have changed in TFS 2010 you have to roll your own implementation for deployment. We used MS build to build MSIs using Wix, then had the testers test the deployment process for us.
Have a look at the following msbuild extensions to help with deploying to test/live environments:
http://msbuildtasks.tigris.org/
http://msbuildextensionpack.codeplex.com/
I would really recommend you spend a little time on your build process and get it water tight, there is nothing more embarrassing that deploying a release to live that doesn't work and the client loosing faith over it.
I don't believe there is a built-in mechanism in Team Build to publish websites, however this can be achieved by overriding AfterDropBuild or AfterEndToEndIteration in your build definition to include necessary tasks for copying the build output to your web servers.