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.
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:
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/
projekt202 is the leader in experience-driven software strategy, design and development. We have a unique and established methodology for understanding people in context — we reveal unmet needs — which drives everything we do. This leads to a crisp, clear understanding of the customer, which shapes the design and development of new solutions and experiences. We have the expertise, teams, skills and scale to deliver sophisticated software solutions that improve any and all touchpoints across the user journey.
projekt202 has spent over 15 years bringing to life and to market compelling experiences through our Experience Strategy & Insight, User Experience, Software Development, Marketing & Analytics, and Program Management practices. Our talented team has delivered emotionally-rich and intuitive solutions for global brands and clients such as 7-Eleven, Capital One, Dell, Mercedes-Benz Financial Services, Neiman Marcus, Samsung Electronics and The Container Store, among many others.