Is it possible to configure Azure Repos or custom repos? This provides more functionalities including branching policy, pull request and code review.
Currently, Git is enabled by default, pointing to Azure centralised database.
https://learn.microsoft.com/en-us/azure/api-management/api-management-configuration-repository-git
In short:
No, this is not possible.
The longer answer:
No, I don't think this is possible.
Although there's no documentation that states it is not possible, I can also not find any documentation it is possible. And the lack of UI, REST APIs or documentation on how to specify a custom Git repo leads me to believe this is currently not possible.
The SCM endpoint is one of the managed service components hence it is out of your control.
Related
Is it possible to authenticate Artifactory OSS (self-hosted) with Azure AD/SAML? Right now we use local Active Directory, but are thinking of deprecating local AD in favor of Azure AD, and moving most authentication to Azure AD/SAML. I understand the other versions of Artifactory can do this, but I can't definitively find if the self hosted OSS version does. If it does not, it may drive us to one of the pay models.
Thanks for any help!
The SAML SSO is not supported in the OSS version of Artifactory. In the link provided, you might find useful information on the top right of the page for JFrog Subscriptions that support the feature (relevant to all features).
Also, you can check the Pricing page for the different features included in each subscription. You should find the SAML SSO feature under the "Pro" subscription level and "Platform Security".
I hope this clarifies more.
When deploying resource in Azure, the default location is always Central US.
Is there any way to configure a preferred location? I cannot find any documentation about this.
It is not supported as of now. It could be due to few reasons a company might prefer deployments across various regions and different subscriptions.
However if you badly need this upvote this uservoice
When deploying the resource in the portal, it will not choose the preferred location for you automatically. But you could choose it manually by yourself, generally, we consider it from compliance to resiliency features.
To find the Azure geography that meets your needs, you could follow this link.
https://azure.microsoft.com/en-us/global-infrastructure/geographies/
As I see I need to create new linux app service.
Recreate domain, certificates binding and deployment pipeline.
And then remove old one.
Is it simplier way to do this?
As Jim Xu mentioned it is currently not possible to move the WebApp from Windows based to Linux. You may have to redeploy the App, leverage the same code with slight modifications and configuration changes as per the requirement.
Cloning feature is not available at the time of this writing. Also, currently there is a limitation - You cannot create a Linux Web App in an App Service plan already hosting non-Linux Web Apps.
Copying the Uservoice post here for clarity & convenience:
" Unfortunately we can’t provide this feature as there are too many internal dependencies for the underlying OS that would make this complex and potentially breaking for solutions. There definitely could be languages that might be supported but they would an edge case."
We really appreciate your feedback/suggestion, so kindly up-vote the Uservoice post -All of the feedback you share there will be monitored and reviewed by the Microsoft engineering teams responsible for building Azure.
Background
I am attempting to using the git command line utility on WSL and Linux to access GIT repositories on Azure DevOps. According to Microsoft documentation found here.
For non-Microsoft tools that integrate into Azure DevOps but don't support Microsoft account or Azure AD authentication, you must use PATs. Examples include Git, NuGet, or Xcode.
A PAT is a Personal Access Token.
A PAT allow for 30+ scopes of access and a scope has multiple sub-options.
For clarity I am referring to this form.
Question
Besides the code scope (which is obvious), are there any other permissions/scopes which should be enabled for git to be fully functional when interfacing with Azure DevOps?
No, you dont need any other scopes to work with the repo. I'm also quite certain you dont need manage permissions, but I didnt test this hypothesis.
You can see the detail information about all scopes here. What scope you can set is detailed in the scope list. If you use GCM on linux to connect remote Git repository hosted in VSTS, the GCM will open a web browser window so that you can authenticate and authorize access to your account, it will create a PAT scoped for vso.code_write, effectively granting Git permission to read and write to your Git repositories hosted in VSTS. I am not sure fully functional in your post means full access.
My company developed an Azure Resource Manager-based solution that deploys a set of resources (essentially a Storage, SQL DB and Web App), and it is already implemented as our provisioning process for new customers.
However, we are now studying the best way to perform updates, and one of the hypotheses we are considering is having a specific template that updates the binaries of this application.
The idea is to have a separate template, that only has the web app, an app host and a MSDeploy resource that gets the latest version of our package and reuploads it to that web app.
The only problem I'm seeing with this solution is the ability to handle any changes in configuration that are necessary with newer version of the binaries - we do not want users to have to re-input any parameters they placed for the original deploy (done via a Deploy To Azure button), so, any configurations will have to be performed within the application - the plan is for it to use the Microsoft.WindowsAzure.Management.WebSites library.
The major limitation with using Microsoft.WindowsAzure.Management.WebSites is that you are restricted to authenticating with either a certificate or a service principal. Ideally we would like to find a way for the updates to not need any authentication other than the one you provide when you are deploying the update.
Is there any recommendation of best practices to follow for this kind of scenario?
Thank you.
Link to the equivalent discussion on TechNet
It is possible to update only via ARM templates.
For example connection strings can be added automatically to the application settings even when creating the dependent resources themselves.
Ex. Account storage connection string.
Only first time creation of your web sites will take a bit more time, something like 30 sec.
ARM will not destroy your WebApps if they exist already. it will update only.
If there are no changes, then the deployment is very fast.
If your changes require a new Appsettings parameter, you can enter it in ARM , check in to your repository.
and next deployment will pick up and update the WebApp.
So no need for anyone to log-in and update.
Our final decision was to give up on using ARM exclusively. The Service Principal solution, through the SDK, would allow us to use a Web Job or a Site Extension to perform (automatic or prompted) updates that included configuration changes. However, it would require "too many" privileges - why would a customer trust an application that can, at will, create new resources or update existing ones to increase his Azure bill?
The decision was made to utilize Powershell only for updates - if the customer can see the scripts and authenticate himself, this is not a concern. Sadly, this increases update complexity, but we found it to be a necessary evil.