- Accounts in Computer Science
- Application Services
- External Services
- Instructor Resources
- COSI Accounts
- Department Apps
- Network Drives for COSI Storage
- Gitlab CI/CD
- Devops for Webhomes
- Working Remotely
- Group Websites using Git, Hugo & Netlify
- Frequently Asked Questions
Gitlab provides built-in fuctionality to enable developers to use Devops procedures to enable [Continuous Integration] and [Continous Delivery/Deployment] using Gitlab build/test pipeines.
Developers can create automated triggers that take place upon a successful git commit/push/merge of source code which results in automated build and testing procedures, possibly followed by automated delivery and deployment to waiting production servers.
Gitlab CI Pipelines
Automating build/test/deployment with a Gitlab CI Pipeline requires 2 components:
.gitlab-ci.ymlfile stored in the base directory of the git repository. This file contains the automation instructions for the build, test, deployment procedures that will be triggered on a successful push/merge. The Department has created a few sample .gitlab-ci.yml files that can perform some simple build/deployment activities.
A gitlab-runner executable must be running somewhere in your build environment. The runner can either be a
sharedrunner installed on an application server that you have been given access to by an instructor or an administrator, or a
privaterunner that you have configured and have running locally on your laptop.
The gitlab-runner executable will execute the procedures found in your repositories
.gitlab-ci.yml file. The computer executing the gitlab-runner process needs to have installed all of the software required to complete any test procedures you have defined in your
.gitlab-ci.yml file as well as the software necessary to compile/build your source code and deliver/deploy your built source code to its production destination.