I have two sites set up in Azure, a staging site and a production site.
Both sites are connected to the master branch of my git repository.
The stage site gets automatically updated when I commit a change to the master branch. What I'd like to do is have production set up so that it won't automatically be updated, but I can manually update it when I want to.
Basically so that changes will get pushed to stage, and when I'm ready for them to go to production, I can manually push them.
Is there a way to do that in Azure?
You have a couple of options:
Use a separate branch to deploy to production. For example a release branch. When you commit to the release branch, production will be deployed. This way you decide when will be deployed to production.
Another option, which is a bit more work. (especially if you have not done it before), but has it's advantages because of more control over the deployment:
Create a VSTS account in Azure. In the VSTS account create a project. Setup a build against your source to create artifacts which can be used in release management. Create a release which can deploy to Staging, and for example after a approval to production. (It's also possible to configure a swap here if you like, to release to producton)
For information about this:
https://www.visualstudio.com/en-us/docs/build/apps/aspnet/aspnet4-to-azure
https://www.visualstudio.com/en-us/docs/build/apps/cd/deploy-webdeploy-webapps
Related
I am setting up an environment for ADF. I have multiple projects and Segments which I need to support. I have noticed that I can only set up one publish branch in ADF.
Should we create ADF for each project?
What is the recommended approach for setting up an environment ?.
Multiple ADFs are required if there is complete different project with different data. If you want to work in same project and just need to manage different environment like development, testing and prod; all this can be managed in one ADF.
A developer creates a feature branch to make a change. They debug their pipeline runs with their most recent changes. For more information on how to debug a pipeline run, see Iterative development and debugging with Azure Data Factory.
After a developer is satisfied with their changes, they create a pull request from their feature branch to the main or collaboration branch to get their changes reviewed by peers.
After a pull request is approved and changes are merged in the main branch, the changes get published to the development factory.
When the team is ready to deploy the changes to a test or UAT (User Acceptance Testing) factory, the team goes to their Azure Pipelines release and deploys the desired version of the development factory to UAT. This deployment takes place as part of an Azure Pipelines task and uses Resource Manager template parameters to apply the appropriate configuration.
After the changes have been verified in the test factory, deploy to the production factory by using the next task of the pipelines release.
Note
Note: Only the development factory is associated with a git repository. The test and production factories shouldn't have a git repository associated with them and should only be updated via an Azure DevOps pipeline or via a Resource Management template.
I have create an ASP.NET Core web app in Azure.
I have followed this documentation:
https://learn.microsoft.com/fr-fr/azure/app-service/quickstart-dotnetcore?pivots=platform-linux
Everything works, but I have create a new develop branch. Each time i push something in the branch, the deployment script is fired. Fortunately, it only deploys master branch on production. So if i have no merged files on master, it deploys the same files. But it might cut the website during a few seconds.
Is there a way to avoid the deployment when i am pushing something on develop branch ?
Thanks
Each developer on our team forks the production repository, then opens MRs from their fork to merge into the master branch of the production one.
We have a fixed number of test environments which are shared by all developers. Eventually we hope to move to ephemeral environments for each MR but at the moment this is not possible.
We utilize the Environments / Deployments functionality of Gitlab: https://docs.gitlab.com/ee/ci/environments/ and the production repository is the central location where we see what is deployed to each environment.
The problem is that when a developer opens a MR they frequently choose to manually deploy to one of our shared test environments. But since the pipeline for their branch runs in their fork it records the Environment / Deploy information there rather than in production. This makes it impossible for us to know who deployed what to each test environment as that information is recorded in random developer forks rather than in the centralized location.
We only deploy to production hosts from the production repository (it is disabled in developer forks) so that information is centralized and up to date. But it is a headache for developers to determine who has deployed something to one of the shared test environments and they frequently overwrite each others' changes by accident.
Is there any way for us to allow test deploys from developer branches, but centralize the information about what is deployed in each environment in the production repository?
Is that possible?
It would be very convenient, to have all branches with an open PR deployed somewhere, where I can have a shareable link.
There are the PR-Branch Triggers, but AFAIK it can only deploy one branch to one environment at the time. And another PR update would just overwrite the state.
EDIT to clarify what I mean:
Each feature branch (or bugfix or whatever) of our webapp should be deployed to an app service (or whatever), so when we create the feature, we always have a link to share during development, in which our designers (or whoever) could find issues in early development. At another cloude storage provider, we had something like that and we would always receive a unique link after successful deployment.
I'm a bit late but working on this now. What I intend to do:
Pull request on selected feature branches triggers task 2
Task will create app services via Terraform (Link)
Use the 'app service deploy' task to push the artifact from that pull request to the new app service created in the prior task.
We'll see how it goes
If deploying each feature branch to an app service is what you are trying to achieve.
You can try below steps(Only for classic pipeline view):
1,In your CI build pipeline, Go to triggers page, add each of your feature branch to branch filters, So that each Pull request made to your feature branch can trigger a build.
2, in your CD release pipeline(Classic view), add different stages, each for an artifacts which built from feature branches:
3, for each stage, In the pre-deployment conditions page, add an artifacts filters to its corresponding feature branch. So that the artifacts from this specific feature branch will trigger to deploy its corresponding stage.
4, Change the settings and parameters of the tasks in each stage according to each feature branch. So that each app service deployed for each feature branch has its own settings and configurations,
5,Configure your app service deploy tasks in each stage.
With above steps done,each time when a new pull request is merged to the feature branch, the corresponding stage will be automatically triggered to deploy this pull request to the configured app service.
My team has an Azure App Services Web App where we house three major components:
Our main Node.js server and API, which is at the root
A secondary API, which is in a virtual directory
Our front-end web app (also served from a Node.js server), which is in another virtual directory
Each of those three components is maintained in its own git repo in VSTS. Additionally, the Web App has three slots: dev, ppe, and prod.
We are trying to move our build processes out of Azure and into VSTS. What we'd like to be able to do is the following:
When there's a new commit to master in any of the three repos, create a dev build and deploy it directly to the appropriate virtual directory in the dev slot.
When a component is ready to be released - whether that means a new commit in a special RELEASE branch or manually triggering a release process - create a production build, deploy it to ppe and, on user approval, swap the ppe and prod slots.
The complication here is that, when any component is deployed to ppe, we also need to deploy the latest released versions of all three components to ppe, since Azure does not have the ability to swap virtual directories independently.
What I currently have is the following:
A build process for each of the three repositories, which is triggered on commits to master or RELEASE. It creates both a development build and a production build and publishes them.
A dev release process that is triggered on any new builds of master in any of the three repositories. It takes the latest dev build from master from all three repos and deploys them to their appropriate virtual directories in dev.
A production release process that is triggered on any new build of RELEASE in any of the three repositories. It takes the latest production build from RELEASE from all three repos, deploys them to the appropriate virtual directories in ppe and, on user approval, swaps ppe and prod.
This works, but it seems pretty clunky, has a lot of wasted work, and it doesn't feel like we're exactly taking advantage of the power of the VSTS build/release pipeline. Is there a better or more accepted way of doing this?
There is Filters based on the artifacts feature in environment triggers of release, so you can base on the build tag(s) to trigger corresponding environments.
Regarding build, you can set the build tag(s) per to current branch by calling logging commands through PowerShell task (##vso[build.addbuildtag]build tag)
Regarding ppe scenario, I recommend that you can create a new CI build definition just for ppe related branch and build all components (get others source code by calling git clone command through Command Line task or other tasks (e.g. PowerShell)), then publish results of them, after that deploy them to corresponding slots and Virtual directory in release.