So I decided to start my first article on dev.to by discussing how to set-up Continuous Integration (CI) and Continuous Delivery (CD), feedback is welcome it helps!
Continuous Integration (CI) is a practice that requires developers to integrate code into a shared repository several times. Each check-in is then verified by an automated build, allowing teams to detect problems to fix early.
Continuous Delivery (CD) is a software engineering approach in which continuous integration, automated testing, and automated deployment capabilities allow software to be developed and deployed with minimal human intervention.
Having a proper CI/CD environment will enable bugs to be caught earlier and developers can review code faster and fix it.
By the end of this article, you will have the basic understanding on how to set up a CI/CD environment on Gitlab.
Step 1: Create a Project on Gitlab
Gitlab is a web-based Git-repository manager, where code can be hosted. Sign up for an account if you do not have one, or log into your existing account if you already have an account. Create a repository, you can name it anything you like, you can also choose to either make the repository public or private. A public repository is accessible to the public through search or direct access using the project’s URL, conversely, a private repository is only accessible to members invited to the repository by the Owner or Maintainer.
Step 2: Setting up your CI environment
To setup a CI environment, you will need to create a file named .gitlab-ci.yml and it should be in the root of your repository.
This file contains a steps by step description on how your project will be built. The Gitlab runner will search for this file in your repository and execute it. GitLab CI looks for this particular file within your repository to determine how it should test the code.
You can create this file through your already created Gitlab project or via your terminal. I will be using terminal in this tutorial. I love my bash commands😏😏
Open your terminal and move to the directory where the project file is located then create a file named .gitlab-ci.yml by doing this:-
$ touch .gitlab-ci.yml
Next we have to edit the .gitlab-ci.yml file so we can create our CI configuration by doing this:-
$ nano .gitlab-ci.yml
The CI configuration will look like this and should be inside your .gitlab-ci.yml file:-
image: node:latest
stages:
- build
- test
cache:
paths:
- node_modules/
install_dependencies:
stage: build
script:
- npm install
artifacts:
paths:
- node_modules/
testing_testing:
stage: test
script: npm test
Let’s understand what the above snippet is all about
The configuration file starts by declaring a docker image that allows you to specify a certain version of NodeJS you want to use during build time.
image: node:latest
Next, we define the different continuous integration process it will run.
stages:
- build
- test
Now we’ve defined the stages, the configuration includes a cache that specifies files that should be saved for later to be used between runs or stages.
cache:
paths:
- node_modules/
Next is install_dependencies, in the process of demonstrating the interaction between stages, we are extracting this step to run its own stage. Typically, running npm install can be combined with the next testing stages.
install_dependencies:
stage: build
script:
- npm install
artifacts:
paths:
- node_modules/
Lastly, testing_testing declares the command that will run the test suit, Since this is the last stage, it will access what is been produced by the build stage, which are the project dependencies in our case.
testing_testing:
stage: test
script: npm test
Oh yea, testing_testing is just a name I used, you can name it anything you want.
Step 3: Installing Gitlab Runner
Since our repository includes a .gitlab-ci.yml file, any new commits will trigger a new CI run. If no runners are available, the CI run will be set to "pending".
As mentioned, in GitLab, Runners run the jobs that you define in .gitlab-ci.yml. I will be following the instructions here.
Step 4: Register the Gitlab Runner
Next, register the Gitlab Runner by following instructions here.
Running the runner executor on shell is the easiest to setup, so after registration, install and start the service with this commands:
$ gitlab-runner install
$ gitlab-runner start
To be sure your runner is running run this command:
$ gitlab-runner status
If you see this: gitlab-runner: Service is running! and the green tick on the project you created on gitlab
Conclusion
Hopefully this article has widen the borders of Gitlab CI/CD and enriched your understanding and like I said earlier feedback is welcome and just in case I missed something kindly notify me.
Top comments (5)
You should NEVER use artifacts to pass dependencies between jobs. Uploading hundreds of MBs just to download them in the next job is a waste of space, time and bandwidth. You should use cache.
True.
Cache vs artifacts details the difference between cache and artifacfs. In a nutshell, cache for dependencies, artifacts for the application bundle/artifact/package.
I will be kind with my words; This article teaches nothing
Don't use Artifact for node_modules, use GitLab Cache instead: docs.gitlab.com/ee/ci/caching/ !
Where is CD? can you add steps for Deployment as well.