-
Notifications
You must be signed in to change notification settings - Fork 0
Continuous Integration
During the development of the project, we have used the in-built CI/CD feature of GitLab, namely via GitLab Pipeline and Runner, to automate tasks regarding the website-based application implemented with the user of Vue.js and Node.js. The CI/CD feature of GitLab is a powerful tool that allows us to automate the process of building, testing, and deploying the application. In this section, we will discuss the CI/CD process of the project.
The CI/CD process of the project is implemented via the GitLab Pipeline and Runner. The GitLab Pipeline is a set of jobs that are executed in a sequence. Each job is executed in a separate environment called Runner. The Runner is a server that executes the jobs in the Pipeline. The Runner can be configured to execute the jobs in different environments, such as Docker containers, Kubernetes clusters, or GitLab virtual machines. In our project, we have used a Docker container as the Runner to execute the jobs in the Pipeline.
The Pipeline of the project consists of the following jobs:
-
install-job- installation of the dependencies of the project vianpm -
lint-job- linting of the source code of the project viaeslint(for the subsidiaryVue.jsapplication) -
test-job- unit testing of the source code of theVue.jscomponents with the help ofvue-test-utilsandvitest -
build-job- building of theVue.jsapplication into a static website vianpm -
deploy-job- ultimate deployment of the website (based on thebuild-job) to a pre-configuredNetlifyenvironment vianetlify-cli
TODO: Migrate the Pipeline Configuration (GitLab-based) to GitHub's Actions.
The configuration of the Pipeline is defined in the gitlab-ci.yml file in the root of the repository. It can be found here.
It was emphasized in the project that the Pipeline should be efficient, well-documented, and structured, hence the separation to standalone jobs.
As indicated in the previous section, the Pipeline of the project consists five jobs. In this section, we will discuss each job in detail.
The install-job is the first job in the Pipeline. It is responsible for installing the dependencies of the project via npm. The command npm relates to a package manager for the Node.js runtime environment. The installation process itself is attainable since package.json, package-lock.json are present in the root of the repository. The package.json file contains the list of the dependencies of the project, whereas the package-lock.json file contains the exact versions of the dependencies of the project. Therefore, we keep a clear track of the dependencies of the project, so the installation process is consistent and reliable.
Bearing in mind that the install-job is the first job in the Pipeline, it is executed in a Docker container with the Node.js runtime environment installed. The Node.js runtime environment is required to install the dependencies of the project via npm install.
Resources:
The lint-job is the second job in the Pipeline. It is responsible for linting the source code of the project via eslint. The command eslint relates to a static code analysis tool for identifying problematic patterns found in the source code of the project. Therefore, the lint-job is responsible for ensuring that the source code of the project is consistent and error-free. The linting process is configured in the .eslintrc.js file in the root of the repository. The .eslintrc.js file contains the configuration of the eslint tool, such as the rules and plugins.
Similarly to the previous job, the lint-job is executed in a Docker container with the Node.js runtime environment installed. The Node.js runtime environment is required to execute the eslint tool.
Resources:
Indeed, a project without testing is a project that is bound to fail. The test-job is the third job in the Pipeline. It is responsible for unit testing the source code of the project via vue-test-utils and vitest. The vue-test-utils is a library that provides a set of utilities for testing Vue.js components. The vitest is a library that provides a set of utilities for testing Vue.js components with the help of vue-test-utils and vite.js.
The individual unit tests are contained under terminarium-web/src/tests/unit directory. The unit tests via the test-job are, likewise, executed in a Docker container with the Node.js runtime environment installed. The Node.js runtime environment is required to execute the vitest tool. Vitest as a subsidiary tool of vite.js is configured in vite.config.js file in the root of website-based application.
Resources:
Coming to the fourth job in the Pipeline, the build-job is responsible for building the website-based application into a static website via npm. The build-job is a prerequisite for the deploy-job. The build-job is executed in a Docker container with the Node.js runtime environment installed. The Node.js runtime environment is required to execute the npm tool. Furthermore, as part of this job, an artifact is generated. The artifact consists of the build directory of the website-based application. It can be obtained within the GitLab environment, under the Pipeline of the project.
Lastly, the build process is dependant on the vite.js tool.
The deploy-job is responsible for deploying the website-based application to a pre-configured Netlify environment via netlify-cli. The deploy-job is executed in a Docker container with the Node.js runtime environment installed.
Note: the deploy-job does not deploy build to the production environment. Instead, it deploys build to the staging environment. Instead, the production environment is to be executed by the developer manually, namely via npm run deploy:prod. The deploy:prod command is defined in the package.json file in the root of website-based application.
This way, the website-based application can be previewed in a website browser, before it is deployed to the production environment. The production environment is the live environment of the project. It is the environment that is accessible to the end-users of the project, and must be thus taken with the utmost care.
Observe: the deployment process defined via npm (through package.json's configuration) is different from the deployment process defined via the deploy-job. Put simply, if a user (or the develop, or any person interacting with the project) executes npm run deploy/npm run deploy:prod on a local machine, they will be prompted to enter the Netlify credentials and go through the authentication process. On the other hand, in terms of the pipeline, it is not possible to proceed with such authentication process. Instead, the env variables are defined in the settings of GitLab project, and then, in the script of the job, invoked via the $SECRET_NAME notation to get the value of the env variable.
Suppose we included the
.envfile under VCS - the.envfile would contain theNetlifycredentials. This would be a security issue, as the.envfile would be accessible to anyone with access to the repository. Therefore, theenvvariables are defined in the settings ofGitLabproject, and then, in thescriptof the job, invoked via the$SECRET_NAMEnotation to get the value of theenvvariable, as stated above.
To further document the process, this excerpt is taken from the .gitlab-ci.yml file in the root of the repository:
'Deploy the project with a log' - use the environment variables to authenticate with Netlify and select the site to deploy. Observe: this is different than the deploy script defined in the package.json file; the reason is, that the GitLab platform is given the environment variables via the CI/CD settings. On the other hand, on the local level, the environment variables are given within the shell instance, and hence
npm run deployis sufficient (the netlify-cli package is installed locally and has the access to the environment variables via an authentication process).
Ultimately, an artifact is provided, namely deploy.log which emulates the deployment process. The deploy.log file can be obtained within the GitLab environment, under the Pipeline of the project. To do so, it relies on the tee unix command.
Resources:
Overall, the experience with CI/CD was very positive. For most of the team members, this was their first interaction with such concepts. Nevertheless, the learning objectives of the project were achieved (in term of CI/CD), and the team members look forward to further broaden their knowledge in the field of CI/CD.
Terminarium Wiki 2023, DIT113, University of Gothenburg | Chalmers University of Technology, Sweden