I've been a big fan of your lessons back in the time! Thanks a lot for all these invaluable lectures - videos are incredibly well-structured, with detailed explanation of nuances. Yet, they are still easy and fun to watch! I think I already recommended the channel to everyone whom I know starting their journey with Azure.
I really like your videos. Your videos are making my learning process easy with drawings and given examples. You are simplifying complicated topics in a way everybody can understand. It shows you have real mastery on your subject. I am commenting under this video but I watch many of your videos from this series. Thank you for your videos and please continue creating more. You have no idea how much you are helping me with my learning process.
43:02 After we created the hot fix branch from commit code and fixed the code why did we trigger the pipeline first from the branch and push to DEV and Prod when we could have pushed to the main and the pipeline will be triggered normally and will give the same result! what is the problem with that?
At this point, main branch might already contain changes that are not yet on Prod (maybe they are now being tested on UAT/TEST), we can't deploy them together with the hotfix and that's why deployment should happen from the hotfix branch instead of main.
@TybulOnAzure Thanks a lot for responding Mr. Piotr, but what happened eventually after deployment is that you pushed the hot fix to main and rejected changes of the breach that was on UAT/Test Wouldn't it give the same result as I mentioned above(in this scenario), or iam still missing part here related to the package creation or multi deployment to main!?
@amonged911 branch that was deployed on UAT didn't have the fix applied so the sequence would be as follows: 1. Hotfix is deployed directly to PROD - issue fixed on PROD. 2. UAT branch is promoted to PROD - issue reappears on PROD as this release doesn't contain the hotfix. That's why this CI/CD pipeline was stopped.
Zapytam w języku polskim: hotfix był zrobiony na podstawie PR z Feature1, który posiadał tylko Activity1 w CICD_Demo, manualnie przeniesiony z hotfix brancha do live mode przez cicd pipeline (omijając maina?), a potem podniesiony na proda (bug załatany). Po tym był zrobiony tradycyjny PR hotfix brancha do maina (zsynchronizowany z live mode). Przez to, że wcześniej był PR do maina z Feature2 w którym były dwa komponenty - Activity1 i Activity2, z których wyłącznie Activity1 zostało zmodyfikowane, a Activity2 pozostawione bez zmian, Devops nie miał konfliktu wynikającego z faktu iż w CICD_Demo na hotfix branchu jest tylko Activity1 a w mainie Activity1 i Activity2 ? (ja bym się bał, że mi wywali CICD_Demo gdzie są 2 komponenty i zrobi replace na taki z jednym :D). Potem podniesienie na prod - wszystko jest na miejscu i możemy zacząć tworzyć kolejny feature branch od maina. Czy ja to dobrze rozumiem, czy gdzieś jest błąd w rozumowaniu?
Wszystko dobrze opisałeś. Co do replace'a - z reguły warto spojrzeć jak wygląda automatycznie zmerge'owany kod, bo czasami faktycznie głupoty się potrafią zrobić.
Great tutorial! Really helped understand git integration with ADF - Thank you! I'm half way through the video but I did want to ask if you show the building the CI CD process? When you merged the PR to main branch, it triggered the CI CD process but how do we create this process? or is this not included intentionally in this video?
Hi Tybul! I have a quick question, when you created the hot fix branch using the commit id (I believe it is called), how did it know that the feature 2 was already in DEV live mode? Does the process tries to merge the commit id code with the live mode code?, I hope my question makes sense. Thanks a lot for the videos they are really helping me grow my professional knowledge. :)
Hi, basically your main/master branch represents your DEV live environment as every commit to it results in an automatic deployment. So actually you have two ways you can check what is in DEV live: 1. Take a look at your DEV environment in Azure DevOps and analyze all deployments made there. 2. Check your main/master branch. In case of ARM-based deployments, we are essentially replacing already deployed stuff with the new one so when I manually do the hotfix deployment, it will just remove everything that is not in it (FB2 in our case). The actual merge of the hotfix with your main/master branch happens at the end - when you do the PR. And then git will try to automatically merge those changes and sometimes it might need your help - in case of merge conflicts.
Hi Tybul! I write to you from Argentina. I am following your channel very carefully and it is of great help to me at work. I have a question. I'm using Azure Devops Pipelines to automate a job and I'm currently using my personal token to authenticate to databricks and interact with the databricks cli from the VM running Azure Devops. I want to stop using my personal token and start using service principal. Should I first create a connection service from Azure Devops to my resource group? And then how should I authenticate from Azure Devops to interact with databricks using the yaml file? Thank you for sharing your knowledge with us!
![Blox Fruits Dragon Rework Update [Full Stream]](http://i.ytimg.com/vi/EqDAp8udhm0/mqdefault.jpg)
I've been a big fan of your lessons back in the time!
Thanks a lot for all these invaluable lectures - videos are incredibly well-structured, with detailed explanation of nuances. Yet, they are still easy and fun to watch!
I think I already recommended the channel to everyone whom I know starting their journey with Azure.
Thanks! It really means a lot to me.
I really like your videos. Your videos are making my learning process easy with drawings and given examples. You are simplifying complicated topics in a way everybody can understand. It shows you have real mastery on your subject. I am commenting under this video but I watch many of your videos from this series. Thank you for your videos and please continue creating more. You have no idea how much you are helping me with my learning process.
Glad you like them!
A very good video demonstrating the DevOps in Azure
Have got good start to know how azure devops will look like!! Thanks Tybul!
Amazing explanation. Thank you a lot..
Glad it was helpful!
As usual great course, Thank you so much
Amazing explanation. Thank you very much...👍🙏
Glad you liked it
I'm really interest for this videos. Thanks a lot. 👌
43:02
After we created the hot fix branch from commit code and fixed the code why did we trigger the pipeline first from the branch and push to DEV and Prod when we could have pushed to the main and the pipeline will be triggered normally and will give the same result! what is the problem with that?
At this point, main branch might already contain changes that are not yet on Prod (maybe they are now being tested on UAT/TEST), we can't deploy them together with the hotfix and that's why deployment should happen from the hotfix branch instead of main.
@TybulOnAzure Thanks a lot for responding Mr. Piotr, but what happened eventually after deployment is that you pushed the hot fix to main and rejected changes of the breach that was on UAT/Test
Wouldn't it give the same result as I mentioned above(in this scenario), or iam still missing part here related to the package creation or multi deployment to main!?
@amonged911 branch that was deployed on UAT didn't have the fix applied so the sequence would be as follows:
1. Hotfix is deployed directly to PROD - issue fixed on PROD.
2. UAT branch is promoted to PROD - issue reappears on PROD as this release doesn't contain the hotfix. That's why this CI/CD pipeline was stopped.
Zapytam w języku polskim:
hotfix był zrobiony na podstawie PR z Feature1, który posiadał tylko Activity1 w CICD_Demo, manualnie przeniesiony z hotfix brancha do live mode przez cicd pipeline (omijając maina?), a potem podniesiony na proda (bug załatany). Po tym był zrobiony tradycyjny PR hotfix brancha do maina (zsynchronizowany z live mode). Przez to, że wcześniej był PR do maina z Feature2 w którym były dwa komponenty - Activity1 i Activity2, z których wyłącznie Activity1 zostało zmodyfikowane, a Activity2 pozostawione bez zmian, Devops nie miał konfliktu wynikającego z faktu iż w CICD_Demo na hotfix branchu jest tylko Activity1 a w mainie Activity1 i Activity2 ? (ja bym się bał, że mi wywali CICD_Demo gdzie są 2 komponenty i zrobi replace na taki z jednym :D). Potem podniesienie na prod - wszystko jest na miejscu i możemy zacząć tworzyć kolejny feature branch od maina. Czy ja to dobrze rozumiem, czy gdzieś jest błąd w rozumowaniu?
Wszystko dobrze opisałeś. Co do replace'a - z reguły warto spojrzeć jak wygląda automatycznie zmerge'owany kod, bo czasami faktycznie głupoty się potrafią zrobić.
Great tutorial!
Really helped understand git integration with ADF - Thank you!
I'm half way through the video but I did want to ask if you show the building the CI CD process?
When you merged the PR to main branch, it triggered the CI CD process but how do we create this process?
or is this not included intentionally in this video?
The next video shows how to set it up from scratch.
Hi Tybul!
I have a quick question, when you created the hot fix branch using the commit id (I believe it is called), how did it know that the feature 2 was already in DEV live mode? Does the process tries to merge the commit id code with the live mode code?, I hope my question makes sense.
Thanks a lot for the videos they are really helping me grow my professional knowledge. :)
Hi, basically your main/master branch represents your DEV live environment as every commit to it results in an automatic deployment. So actually you have two ways you can check what is in DEV live:
1. Take a look at your DEV environment in Azure DevOps and analyze all deployments made there.
2. Check your main/master branch.
In case of ARM-based deployments, we are essentially replacing already deployed stuff with the new one so when I manually do the hotfix deployment, it will just remove everything that is not in it (FB2 in our case).
The actual merge of the hotfix with your main/master branch happens at the end - when you do the PR. And then git will try to automatically merge those changes and sometimes it might need your help - in case of merge conflicts.
Hi Tybul!
I write to you from Argentina. I am following your channel very carefully and it is of great help to me at work.
I have a question. I'm using Azure Devops Pipelines to automate a job and I'm currently using my personal token to authenticate to databricks and interact with the databricks cli from the VM running Azure Devops. I want to stop using my personal token and start using service principal.
Should I first create a connection service from Azure Devops to my resource group?
And then how should I authenticate from Azure Devops to interact with databricks using the yaml file?
Thank you for sharing your knowledge with us!
Hi, take a look here: learn.microsoft.com/en-us/azure/databricks/dev-tools/ci-cd/ci-cd-sp