![]() Please use a new branch in your Repos for the test of this operation following the marks in the picture below. And after I changed the Branch Security Permission, the test branch was unable to be deleted. Having this all in the same pipeline would make the pipeline "hang" while developers are working, potential across days, correct? I don't think that would work for us. 1 Answer Sorted by: 4 I have tested according to your narrative and found that the locked branch could still be deleted. When that PR is merged, running some sort of command (in our case, probably something like helm uninstall) would destroy the resources provisioned when pushed to the feature branch. The developer would work in this isolated environment, making iterative changes and pushing them to the feature/* branch until they're satisfied, at which point they'd raise a PR against develop such that other devs could review the code. I wasn't super obvious with it beforehand but the desired flow would be something like: push to a feature/* branch triggers a deploy (building a container, deploying into a k8s cluster) into an isolated environment specific to that feature (isolated by namespace, or something else of the like). Thanks for your answer, and this is a good thought. Has anyone run into this or can point me in the right direction? thanks. Then create an automation that looks for those tags, do a rest api check to see if it still exists, run hourly, delete if not found. My idea was that when deleting a feature branch, a pipeline run could be triggered that runs "cleanup" logic, but I haven't yet been able to figure out how to do that when browsing the official documentation. Add tags to your resource creation that can be tied to the Azure DevOps organization, project, repo, and branch. The code in your master branch should pass tests, build cleanly, and always be current. This workflow is often called the Feature Branch Workflow or Topic Branch Workflow. I'd like to figure out how to clean up those resources that were created upon commits to the feature/* branches. Once the code changes and history are merged, its good housekeeping to delete the branch. Either when PR is merged or feature/* branch is deleted, can I trigger a pipeline task to "clean up" those resources provisioned in step 1?.When merged, the code is deployed into the shared development environment. ![]() When developer is satisfied that their code works, then raise a PR that is against develop.This involves building a docker image and deploying to a k8s cluster, namespaced specifically to the feature branch to be isolated from other code. commits to feature/* branches are worked on and deployed into a sandbox environment.I currently have branch triggers set to run when a developer commits to a feature/* branch, and when commits are created in the develop branch, with slightly different logic between them. Hey all, I am fairly new to the ADO space, and am looking to build out an initial proof of concept for my team to build and deploy resources using ADO pipelines.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |