Followed this video to edit the pre-made yaml file to add a staging environment. However, I'm unable to add the environment key as is shown in this video @ 3:40 . The YAML editor on Azure doesn't recognize the environment key and shows a yellow squiggly line under it and fails validation as well. Therefore, I'm not able to point this pipeline to the Staging and Production environments I created as per this video. I do get the named preview as staging (due to deployment_environment set to staging) but since I added steps to deploy to production as well in the yaml, and since this doesn't point to the newly created Production environment, I don't get asked any approvals and deployment to production happens immediately after deployment to staging.
Great video Anthony! I have a question, I'm still learning about CI/CD, I've been developing a django web app (locally) in python and i used playwright for the first time. Is it possible to automate playwright tests on azuredevops without deploying? Sorry for the naive question
I believe this is possible, although I'm not sure if it's available in the Python version of Playwright yet. In your pipeline, you should be able to run your Playwright tests and Playwright can automatically start your Django app too so the tests will test it over localhost. This is the configuration for Node.js: playwright.dev/docs/test-advanced#launching-a-development-web-server-during-the-tests
I think that running deployments from a build pipeline is not a good practice. You have shown how to tightly couple a build with deployment to one specific environment. This coupling has many problems - just imagine that your organization has 30 test environments and various test teams want to upgrade and downgrade their environments at will at the time of their choosing and you should start seeing problems with your approach. I think a better architecture is when the build is only responsible for creating a properly versioned artifact that can be copied around and deployed to any environment. IMHO deployments are better done from the release pipelines, separately from builds.
Followed this video to edit the pre-made yaml file to add a staging environment. However, I'm unable to add the environment key as is shown in this video @ 3:40 . The YAML editor on Azure doesn't recognize the environment key and shows a yellow squiggly line under it and fails validation as well. Therefore, I'm not able to point this pipeline to the Staging and Production environments I created as per this video. I do get the named preview as staging (due to deployment_environment set to staging) but since I added steps to deploy to production as well in the yaml, and since this doesn't point to the newly created Production environment, I don't get asked any approvals and deployment to production happens immediately after deployment to staging.
Great video Anthony! I have a question, I'm still learning about CI/CD, I've been developing a django web app (locally) in python and i used playwright for the first time. Is it possible to automate playwright tests on azuredevops without deploying? Sorry for the naive question
I believe this is possible, although I'm not sure if it's available in the Python version of Playwright yet. In your pipeline, you should be able to run your Playwright tests and Playwright can automatically start your Django app too so the tests will test it over localhost. This is the configuration for Node.js: playwright.dev/docs/test-advanced#launching-a-development-web-server-during-the-tests
How to deploy WordPress site on azure static webapp
Can i use github actions to do multi staging too?
I think that running deployments from a build pipeline is not a good practice. You have shown how to tightly couple a build with deployment to one specific environment. This coupling has many problems - just imagine that your organization has 30 test environments and various test teams want to upgrade and downgrade their environments at will at the time of their choosing and you should start seeing problems with your approach. I think a better architecture is when the build is only responsible for creating a properly versioned artifact that can be copied around and deployed to any environment. IMHO deployments are better done from the release pipelines, separately from builds.
Hey man, found this very insightful. Would you be open to talk about it. I want to learn more