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.
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
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
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 stage, we label it as
test_cases and it uses the latest node docker image to run
yarn test-ci and
yarn test-api commands against the current code base.
Here are the
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, 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/