I need to create a script that sets security to a given environment in a given release definition (as input I have TFS url, project ID, release ID and environment ID).
With the script, I need to set all the environment specific permissions:
Administer release permissions
Delete release environment
Edit release environment
Manage deployments
Manage release approvers
I did not find any method for this in the API.
I also tried to sniff the network traffic as suggested in this question. But for this task it looks too difficult. The request body is full of some identifiers (I do not know where how to get them).
The question is: how can I set environment specific permissions via script?
(preferably with PowerShell Invoke-RestMethod)
I think the only way at the moment is to use tfssecurity.exe!
Here is a good guide and also a download of an Excel that helps you to create your tfssecurity statements. You can find tfssecurity.exe in your TFS-Folder.
Link to guide: https://roadtoalm.com/2014/07/28/add-permissions-with-tfssecuritythe-ultimate-reference/
Related
I need help to understand better how to create complete CI/CD with Azure Devops for APim. Ok I already has explored the tools and read docs:
https://github.com/Azure/azure-api-management-devops-resource-kit
But I still have questions, my scenario:
APim dev instance with APi and operations created and others settings, as well APim prod instance created but empty.
I ran the extract tool and got the templates (not all), still need the Master (linked templates), and on this point seat my doubt, I already have 2 repos too(dev and prod).
How can I create the Master template, and how my changes from dev environment will be automatically applied to prod?
I didn't used the policyXMLBaseUrl parameters not sure what Path insert there, although seems #miaojiang inserted a folder from azure storage.
After some search and tries I deployed API's and Operations from an environment to another, but we still don't have a full automated scenario, where I make a change in a instance and that is automatically available.Is necessary to edit policies and definitions directly on the repositories or run the extract tool again.
We have a requirement to update a text file during the release phase in VSTS depending on which environment the solution is being deployed too. I am a complete beginner to this.
I've looked at variables but I'm not clear on whether this will solve this particular problem.
There are many tasks that can update the file during the release, such as RegexReplace Build task (As rickjerrity mentioned), Replace Tokens etc…, you also can do it programming (e.g. PowerShell) during release.
Steps:
Add the environments with same name for each environment (Set Scope)
Using that variable in task.
I'm developing Release pipeline for deploying artefacts using TFS 2017 Update3 Release Management. There are various tasks like "Windows Machine File Copy" and "Run Power Shell on Target machines" which needs admin credentials to be passed as input parameters. These admin credentials have Administrative access on target nodes. I'm using Windows service accounts for these. We have an organisational security policy to rotate passwords every month.
With that in mind, it is hectic to update hundreds of TFS release definitions for new password every month.
Do you have a better idea to handle this? Please give detailed answers.
Thanks in advance.
You could use a variable group to store values that you want to make available across multiple build and release definitions. Variable groups are defined and managed in the Library tab of the Build & Release hub. In this way, you can just edit the variable group:
https://learn.microsoft.com/en-us/vsts/pipelines/library/variable-groups?view=vsts
If you want to automate the process you use the solution defined here. This details how to use the TFS API to poke the definitions.
Alternatively you could create your own PowerShell task that sources the password from some alternative source like Azure Key vault or even hard code it into the json task definition itself (don't do this).
You can vote to improve this story here.
I wrote a custom version of the PowerShell task that uses the identity of the agent as part of the WinRM session which greatly simplifies our release definition process.
I'm using Visual Studio Team Services and I'm trying to set up Release Management to allow automated deployments for our Azure Web App to multiple environments. I would like the same source to be deployed to each environment, but with modified configuration settings.
I was hoping that I could create a single Build for my application, and then modify the configuration at deployment time for each environment. I'm aware that this can be done for appSettings and connectionStrings (either through Tokenization, or even managing those settings via the Azure portal), but I'd like to be able to make more general changes to the web.config file. For example, I want to be able to:
Update 'simple' settings such as appSettings/connectionStrings
Update multiple attributes on elements (like httpErrors)
Insert or rewrite sections of the config file itself (for example to add IIS rewrite rules, or to remove unwanted HTTP handlers for production)
Currently we achieve this by using config file transformations and separate publish profiles for each environment (manual deployment). I can't see a way to re-use this if I want a single release pipeline.
I'm hoping someone can help point me in the right direction. I'm also happy to accept alternative solutions - ultimately I just want to be able to deploy the same source (e.g. from the same commit in source control) to multiple environments, with different configuration, while keeping some kind of flow from dev, to test, to eventually production.
You can use Tokenization Task to update the files base on the environment variables.
More similar extensions: Replace Tokens and Colin's ALM Corner Build & Release Tools.
I have a project that uses Entity Framework 6.x, ASP .NET WebApi 5.x. Data Access is in a secondary project inside the solution. I want to use VSTS (aka Visual Studio Online) to build and release it as a website to environments for integration/dev, qa, stage, and production. There are some great videos on Channel 9 that deal with the generic high-level description. (for example https://channel9.msdn.com/Series/DevOps-Release-Management and https://channel9.msdn.com/Series/DevOps-Fundamentals/Infrastructure-as-Code) There are all kinds of articles and videos about how to do migrations from inside Visual Studio including generating scripts.
Searching around the web I don't even find any older resources or concrete examples of continuous deployment with code first migrations. There must be examples and best practices for methods other than auto-migrations or SQL scripts.
I have configured a Web Deployment Package publish profile. I use it via the PublishProfile msbuild.exe directive. The package is added to the artifacts and then deployed by the Azure Web App Deployment task in each Release environment. However once this package is built, I don't know of a way of changing the connection string in the build package for each time it is released to an environment.
There is probably something I am overlooking, but how should environment specific migrations be done with via VSTS Release?
For Code First Migration, you can "Write App_Start code to run Migrations" or "Write Web.config transforms to configure the MigrateDatabaseToLatestVersion initializer to run", refer to this article for details: http://blogs.msdn.com/b/webdev/archive/2014/04/09/ef-code-first-migrations-deployment-to-an-azure-cloud-service.aspx
For the connection string transformation with profile, you need to add a web.config file for the publish profile and then enter the connection string in this web.config. Refer to this link for details: http://awaitwisdom.com/publish-profile-config-transform/
I hate to answer my own questions here but, ultimately my research took me to the conclusion I am posting at length here. In sort, Web.config and Parameters.xml require some custom scripting that will require you to maintain your own deployment automation. These routes will still require you to additionally create your resource groups or manage them manually.
To avoid these complications and cobbling tools and scripts together, the whole operation can be achieved with two JSON files. These JSON deployment templates allow you to create or update your resource group when your deployment runs. They also allow you to automate setting appsettings and connectionstrings that overwrite your Web.config values in the same manner as you can through the Azure Portal.
the steps: (1) Add the two JSON files to the project setting the name of you connection string on line 88 (2) Add a Azure Resource Group Deployment task to the Release environment. (3) Set Template (WebSite.json) and Template Parameters (WebSite.parameters.json) paths in the task. (4) Set Override Template parameters to -hostingPlanName "myHostingPlan" -webSiteName "myWebsiteName" -connectionString "the-actual-connection-string" (5) make sure you are using the same website name in your Azure App Deployment task.
This does depend on having your code first migrations run via App_Start or something similar. I took the first part of #Eddie's suggestion since App_Start is easy to deal with and doesn't seem to run too often.
As a bonus you can add environment variables for any of this configuration so you can clone the environment and then just change the variables. This ultimately makes your application or api connection string a Release variable.