I'm trying to find how and the best practices for securing access to Microsoft Team Services.
We are looking at auto deployment from Team Services, but we have a concern about it being in the cloud.
Our machines are hosted with a third party and we need to ensure that the deployments only come from our Team Services, is this possible and what are the best practices to ensure the best security possible.
Microsoft do a lot of things to keep your Team Service project safe and secure, refer to this link for details: Visual Studio Team Services Data Protection Overview.
And for your question, you can deploy your own build agent which you can have full control and easy to configure your machines to only accept the deployment from that build agent.
Related
We want to use azure pipelines to deploy application on on-premise virtual machines. We are trying to see if we should use self hosted agents in azure so that we can try to manage access to private network. The tech stack is Microsoft based so we will install visual studio enterprise (for build and code coverage).
What are the best practices in setting up the self hosted agent?
Should there be a specific build user which is linked to visual studio license on the server?
Should there be a specific deploy user that has access on the on premise servers to copy artifacts like IIS websites?
Should there be a specific build user which is linked to visual studio license on the server?
No, you can check that here: https://visualstudio.microsoft.com/wp-content/uploads/2020/03/Visual-Studio-Licensing-Whitepaper-Mar-2020.pdf
Using Visual Studio on the Build Server
If you have one or more
licensed users of Visual Studio Enterprise Subscription, Visual Studio
Professional Subscription, or any Visual Studio cloud subscription
then you may also install the Visual Studio software as part of Azure
DevOps Server 2019 Build Services. This way, you do not need to
purchase a Visual Studio license to cover the running of Visual Studio
on the build server for each person whose actions initiate a build.
Should there be a specific deploy user that has access on the on
premise servers to copy artifacts like IIS websites?
Basically, yes. This user has to have corresponding permissions on target servers. However, you can use tasks that define users like Windows Machine File Copy task and PowerShell on Target Machines task.
I thought I'd read that there was an entire web services API for automating the latest Bluemix DevOps tooling? I don't see anything obvious in the documentation
https://console.ng.bluemix.net/docs/services/ContinuousDelivery/index.html#cd_getting_started
You're right. You can choose to create a toolchain or start from a toolchain template.
You may find this microservices devops toolchain template tutorial helpful.
https://www.ibm.com/devops/method/tutorials/tutorial_toolchain_microservices_cd?task=1
By default, the toolchain comes with these tool integrations:
IBM-hosted Git Repos and Issue Tracking repositories (repos)
Delivery pipelines
IBM Cloud DevOps Insights
The Eclipse Orion Web IDE
Sauce Labs
pagerDuty
Slack
See https://github.com/open-toolchain/sdk/wiki
This is where we are defining the API. Since SO won't let us have a conversation about what you're actual requirements are, feel free to create an issue on the repo to capture them.
Does VS Teams services have an agent to log when a website is published in Visual Studio 2015? I am new to Team Services. I have a small team of developers, 4 including myself. We have recently migrated from TFS 2010 to Team Services. Part of our PCI compliance, we need to log when our sites are published. We currently publish to an IIS server.
No, all actions are in local and not related to VS Team Services, so VS Team Service can’t log anything.
You can build and publish/deploy the web app to IIS through VS Team Service build and release system, then you can check the related information of that build/release (e.g. detail build/release log)
More information, you can refer to this article: Deploy your Web Deploy package to IIS servers
I have been playing around with Visual Studio and Microsoft Release Manager. I have found a couple of behaviors I wasn't expecting and I was hoping someone might be able to confirm these (in case I'm getting the wrong end of the stick).
My goal is to:
Host my code in Visual Studio Online.
Deploy said code to on-premise or Azure hosted VM, using deployment agents.
My first attempt; using the Release Manager service provided as part of Visual Studio Online. However I found that I wasn't able to connect to Release Manager Online with agents deployed on-premise (or in Azure VMs).
I later found this text at https://www.visualstudio.com/en-us/get-started/release/manage-your-release-vs
You have the following options for managing your releases:
Using Release Management as a service on Visual Studio Online: You
need a Visual Studio Online account. You cannot use Chef and you can
deploy only to vNext environments based on Azure IaaS services
Using an on-premises server: You need to install Release Management
Server; do that here.
This seems to suggest that Visual Studio Online Release Manager cannot use agents - is this correct?
Assuming that is correct, my second attempt was installing Release Manager on-premises (so to speak, it is actually in an Azure VM).
I installed the latest RM versions (server, client, agent) from https://www.visualstudio.com/en-us/downloads/download-visual-studio-vs#d-release-management. Specifically, Release Management for Visual Studio 2013 with Update 4 (12.0.31101.0).
However I found that I was unable to connect the on-premise Release Manager to Visual Studio Online. The error message stating that I must supply the user name in 'domain\username' format - which won't match the online 'username#domain.com' format.
This seems to suggest that an on-premise installation of Release Manager cannot connect to Visual Studio Online - is this correct?
Thanks,
Okay, there are a few pieces of the puzzle here:
The Release Management client has to be on Update 4 (or later, when RM 2015 comes out later this year).
If you're using Visual Studio Online, on-prem Release Management cannot talk to it. It's a weird limitation, but there it is. You can hook the RM client up to RM Service in VSO, but that's it.
RM Service in VSO does not support deployment agents. It only supports "vNext" release templates, which operate off of PowerShell or DSC scripts to perform deployments.
Agents are, sadly, quickly becoming deprecated in favor of what's termed "agentless" or "vNext" deployments. Microsoft is currently working on totally revamping the Release Management piece, and the next version (which will be released in TFS 2015 Update 1) will not support agents at all.
If you want to use an on-prem RM server with VSO, you have to use RM without the TFS integration. It's still possible to get the bulk of the continuous delivery functionality, it just requires jumping through a few more hoops.
You'll have to set your components up as "builds externally" and use an on-prem build server
Your RM deployment agents in Azure (obviously) have to be able to talk to your RM server. This could require all sorts of firewall shenanigans, but that's a conversation to have with your networking folks.
If you want to do continuous delivery (where a build triggers a release), you'll have to look at the ReleaseManagementBuild.exe file (which is part of the RM client). This tool is responsible for launching releases as part of the build. The "Release" build process templates assume TFS integration, but the ReleaseManagementBuild.exe application has a "package" mode, where you can specify a UNC path to release. This gets you around not having direct TFS integration. It's possible to hack up the build process template a bit to take advantage of this.
I'm advocating using Visual Studio Team Services for our source control solution, and have actually started doing so. However, my manager, who is somewhat apprehensive when it comes to cloud-hosted storage and services, wants to know what our contingency plan is in the event of Team Services ceasing to be accessible for whatever reason.
I've pointed out that we have our source code on our developers' computers, in their mapped work spaces, but admittedly if we ended up with just that and no access to Team Services we'd certainly be in a bit of bind. They might all be working on different parts of the same solution and we wouldn't be able to check all of their changes back into the central repository or merge changes made in separate branches. We also wouldn't have access to the comments associated with previous check-ins, or our backlog, tests, etc.
So, the question is, is there a way to backup everything that we're hosting in Team Services so that, in the event of something going wrong, we'd be able to restore all of that to a locally-hosted installation of TFS (or somewhere else)?
I'm a bit late to the party but we developed a Team Services backup tool. We scheduled it as a scheduled task and it runs once a night. It then just clones all our repositories to disk.
Taken from this blog:
We use the VSO Rest API to query our VSO account and get all the data
we need. Since in VSO you can only have one Team Project Collection,
we retrieve all the team projects of the default collection. Each of
these team projects can have multiple repositories that need to be
backed up. A folder is created for each team project and saved to a
location on disk that can be configured in the app.config. When the
team project folder is created, the task loops over each repository in
the team project and creates folders for each repository.
You can also fork it on GitHub here
There's no out of the box backup ability.
Now, if you are only referring to source control, and not work items, pull requests, builds, test plans or anything else that the service offers, then I'd suggest you migrate your code over to git.
With git every developer will have a complete copy of the source repository, including all history and commit comments. From there, it's a simple task to push the git repository to a different git hoster (such as bitbucket or github) and make them your new centrally hosted git repository.
On a historical note, Visual Studio Team Services at one point offered a data export for a period of time. You might want to add a vote or three to this related UserVoice idea to help raise the importance of the feature with Microsoft.
Side comment: The business risks in using Visual Studio Team Services will come from either Microsoft shutting down the Visual Studio Team Services service or that the underlying Azure infrastructure has such a catastrophic failure that your Visual Studio Team Services account is unrecoverable. Both of those are extremely low risk, and very likely lower than the risks you'd have running TFS on-premises, in your own data centre, unless of course, your infrastructure and staff are better than Microsoft's :-)
Not a full VS backup in terms of a restore of service. But you can take a full Zip from root down using the Code web site. Right click the root folder and has a zip download option. Pretty neat feature.
The easiest way to back up everything is to use something like the TFS Integration Platform to periodically pull off all your data into an on-premises TFS solution. I've set this up using an Azure VM that we turned off when we weren't actively backing up, which makes it really low cost. For more info on using the TFS IP with Team Services, see this: http://nakedalm.com/migration-from-tf-service-to-tf-server-with-the-tfs-integration-platform/