Switching from Github to Gitlab (PROCESS)

PROCESS

THE SETUP

We are building a front-end/micro-api project based on javascript. It’s ExpressJS serving up a single-page application along with having a few /api routes that essentailly act as a proxy for other backend services out of our development control.

Typically we would use Github, then something like Jenkins for building and some other asset service to hold what we built as a part of our typical development/deployment process; for this new process, it’s a matter of simply providing a Docker image for some other part of the company to consume and this is where Gitlab comes in to be our one-stop solution.

I don’t really go in-depth on the different things Gitlab offers, but I’m adding links in this article to the docs that should give you more info on all the things Gitlab offers.

ENTER GITLAB

Outside of providing a code repo with a built-in wiki, issue tracker and code snippets (pretty standard), it also comes with its own CI/CD as well as private docker registry.

Here is what I did to take the Node/SPA application and create a Docker image that is ready for whomever to consume.

Here is my project layout:

This is a base React-Scripts project with a few things thrown in there to handle the /apiportion. There are two key files that we need to pay attention to and that is Dockerfile and .gitlab-ci.yml.

The Dockerfile has this:

What we are doing here is:

• getting the node JS (version 8) image, based on the Alpine operating system
  
• copying over the code
  
• running yarn (this is like: npm install) and yarn build (Note: yarn comes pre-installed on all NodeJS images)
  
• exposing the nodeJS server on port 80 when a container based on this image is running.
  

The Gitlab CI file has this:

This gitlab CI file (.gitlab-ci.yml) has stages listed with test and build.

For the test stage, we label it as test_cases and it uses the latest node docker image to run yarn, yarn test-ci and yarn test-api commands against the current code base.

Here are the test-ci and test-api commands located in the package.json file, if you are curious:

One command is to test the API endpoints provided by our server code and the other to test the react components.

When Gitlab runs these tests listed in the script section, if there are any failures in the tests, it will block the next thing in the pipeline from happening, which is the build stage.

In the build stage, we use a docker image docker:git to log into the gitlab registry and then issue a docker build command and tag it with 2 different tags, one for the latest and the other versioned with the git commit sha (gitlab offers variables and predefined keywords). The great thing is is that we can restrict this to a specific branch, which if you look at the only section we defined it as master, so this will only run when we update the code in master via push or merge from any other branch.

Once the image is built, we push it to our private registry where anyone with the proper credentials can pull from it.

We have eliminated the need for any other third-party tooling since we are now just using Gitlab to run our tests as well as build our image; and of course version our code. Simple, the way I like it.

There is so much more that can be done for testing, building and deploying, so here is a link to the documentation: https://docs.gitlab.com/ee/ci/

Source:projekt202.com/blog/2019/switching-from-github-to-gitlab