During the configuration of the runner, we can specify what type of executor to use. The execution of the job is delegated to an “executor”. Several runners can (and should) run in parallel, allowing the whole infrastructure to scale. A runner is a software able to receive from GitLab a job, execute it, and send back the result to GitLab. This file contains the commands to execute (a batch of commands is called “job”) on the specified runner. Using this YAML file we can configure the CI/CD behavior: what should happen on every commit or merge request, what should happen at scheduled times, and many many more. The gitlab-ci.yml file that contains the configuration of the CI/CD pipeline.The CI/CD toolchain is composed of 3 main parts: GitLab is a complete DevOps platform: it offers us a complete CI/CD toolchain, an amazing issue tracking suite, and exposes in a user-friendly-way almost every Git’s feature. In the following, “CD” will stand for Continuous Delivery - so I won’t cover the Deployment part. In this article, I’m going to show you how to configure and use the CI/CD tool provided by GitLab to correctly manage the CI/CD pipeline of an Unreal Engine 4 (UE4) project that needs to work (and thus, to be tested) on 3 different platforms: Continuous Deployment where a developer’s change is automatically released to the production environment, where the customer can use this brand-new version.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |