 הי, מי name is Yitzigan Baruch, טכניקל מרקטינג-מנגר עד GeatLab. אני פרקומנטי אסת אם זה אפשר לנהל בין אשור דב אופס-ריפורס וגיטלאב CICD. אז העסר כך זה, yes, זה אפשר. In this video, I will walk you through that. The integration enables you to keep using Azure DevOps Repos to manage your code and use GeatLab CICD to build, test, and deploy your application. This is my repository in Azure DevOps. Now, I will clone it to GeatLab. So I'm clicking here and this is the clone URL. I just click here to copy it to my clipboard. And if this repository was private, I could generate credentials using the password that I can use. This is GeatLab and I will create a new project. I'm selecting the CICD for external repo and repo by URL. And I can paste the URL and the username and password are optional. In my case, my repository is public so I don't need to use username and password. I will give it a name and I will set visibility level to public. Create project now. It's mirrored the project from Azure DevOps to GeatLab. It's going very fast and if you notice this link, mirrored from Azure DevOps, that means that now any branch commit and tags that I push to Azure DevOps will be automatically mirrored via pull command to GeatLab. The next step, I will set up CICD in GeatLab. So any push to Azure DevOps will trigger CICD pipeline in GeatLab. So there are two ways to make it. One way is the easiest one. I will go to CICD settings and I will enable the auto DevOps. One check box. Save changes. My GeatLab CICD is now enabled. For each commit that I will push to Azure DevOps repos, GeatLab CICD pipeline will be triggered. Since I already have a Kubernetes cluster set up at a group level, the auto DevOps pipeline will also have a deployment jobs that will deploy my application into that cluster. Auto DevOps configure your CICD based on out of the box preconfigured CICD templates. In some cases, you will want to use your customized CICD settings. So I will turn off auto DevOps and then what you need is to create a file in the repository. The name of the file is .geatlab-ciyamel. This is the GeatLab CICD configuration file based on YAML. And this is how it looks like. It has all of the stages. You can include also YAML templates and here are all of the jobs that we want to run. So because I have it in the root directory of this repository, I'm all set and now I can just start the development. So I will show you a quick example. I will open your studio code and this is my source code. I will start with create a new branch. Now I will make a change. I will just add here a message powered by GeatLab. I will save this change and commit it in the text. This is my commit message and I will push it to the server. Now I will go back to my server and I can see this commit. I should see it immediately. Branch number five and this is what I added. So this change now should be reflected in GeatLab. So I'm going to GeatLab window and I will go to the branches. And branch five is not here yet. So I will click on update now and I will open the commits. I can see now branch number five and the text and I see this icon means the pipeline is running. I can open the pipeline from here or I can go open it from here and this represents my pipeline graph as I defined in my GeatLab CI CD email. I have a few stages, build, test, review, DAST, performance and cleanup. The build succeeded and now if I will open the container registry, I can see a new folder for my branch. I can click on it and I see the images that it created for my source code. I go back to the pipeline and I see that it started the test stage and it will run a few tests, security scans, license scanning. From here you can access each job and see what's happening. And on the right side you can see details about the job. You can cancel job, you can retry job if a job failed. You don't have to restart the entire pipeline. You can just fix something and restart a specific job. Jobs view presents all of the jobs in a list view instead of the graph. And in this view you can see some more details about each job. If tests are defined in this CI CD pipeline, you will see the test status here in this view. The security tab lists all of the vulnerabilities that the scans found. So once the pipeline is finished and you are satisfied with the test results, you can go back to your code and create a pull request and you ask to merge branch 5 into master and I will create this pull request starting the review process. If reviewers are defined, they can add their comments here and once it is approved, we can complete this pull request and merge the code to master. Complete merge. Once it is merged, this will trigger additional pipeline in GitLab. The new pipeline will run now on the master branch. I will open the pipelines and soon we will see a new pipeline starting and the pipeline will be different because this pipeline will be not only continuous integration pipeline, it will be CI CD pipeline. So here the pipeline has just started. This concludes the demo. Thanks for watching. To keep up to date, check out more videos on our YouTube channel.