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.
Related
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?
I have an application with .NET Core web API and Angular client application which is hosted in Azure as app services. Trying to introduce full DevOps practice to this up until production.
I'm trying to create a release pipeline in Azure DevOps while keeping git-flow as my branching strategy. currently,
I have 5 different environments which are Dev > QA > UAT > Pre-Prod > PRODUCTION.
I know with a trunk-based approach this is pretty easy to configure with one release pipeline which will go through all the environments as one release until it goes to production. In the current setup, this is automated only up to the UAT environment using Only the Development branch as the release pipeline which works pretty well.
I'm wondering what would be the most suitable way to do it keeping git-flow as my branching strategy. Also, relevant branches should automatically tag with UAT and production releases.
Mainly I have a development branch that contains the latest development activities and feature branches will be merged into development after PR approvals and Master is the production equal branch.
With my current environments setup, releasing this to UAT is quite simple with the Development branch but when proceeding to Production it might cause problems.
To keep the question short considering multiple factors, I was planning to have 3 different pipelines as follows
UAT - One release pipeline from development which goes through Dev > QA > UAT
Prod - Master branch will be configured with this pipeline which goes through Pre-Prod > Prod environments. this will be a separate build pipeline which will trigger soon after development merges with the master branch. this will be the main production pipeline. either this could be a master or separate release branch.
Hotfix - This will be the Production hotfix release pipeline with a separate build pipeline which goes through QA > Pre-Prod > Prod.
Will this approach works or any bettor way of doing this. Since this is the very first time planning release it to production through the pipeline. I would like to hear advice from experts?
I'm working on an API in core3.1. We have a build pipeline that builds and unit tests any change for any branch. And release pipelines for development and master branches. These deploy to designated app services in Azure.
Now we would like a release pipeline for feature branches. So what we want is a pipeline that can dynamically created app-services per feature branch and deploy to that app service. And preferably dynamically delete the app-service when the branch is deleted.
Just to clarify, the proces how we would like it:
a developer creates feature branch and pushes it >
the build pipeline builds it >
an app service gets created automatically >
stuff gets deployed to that app service >
developers work on the branch and changes get build and deployed to the app service like normal >
at some later point a developer deletes branch >
app service gets deleted automaticcaly
Is there any way to accomplish this? Maybe there is a standard way?
Feature branches are located in a subfolder, e.g. "feat/feature-branch-name".
I'm fairly new to Azure and DevOps.
Any help is appriciated. Thanks in advance.
You should follow the practice of Infrastructure as Code (IaC) and use ARM templates in your pipeline to create/update/delete your Azure resources. You can also use the built-in tasks available in Azure DevOps to deploy your ARM templates.
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.
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