This demonstration is designed to highlight GitLab’s integrated set of tools for the software development lifecycle, from idea to production, including continuous integration Pipelines, continuous deployment Environments, and Container Registry. It takes about 8 minutes and be done on a single-tenant server, or GitLab.com. It happens to use Ruby/Sinatra and Docker Cloud.
A pre-recorded version is available on YouTube.
Example issue: https://gitlab.com/gitlab-examples/docker-cloud/issues/1
Example merge request: https://gitlab.com/gitlab-examples/docker-cloud/merge_requests/1
Today I’d like to demo some of the power of GitLab’s integrated set of tools for the software development lifecycle, helping you get from idea to production as quickly as possible. We will start with a simple project and will show you the power of built-in continuous integration, built-in container registry, and built-in continuous deployment.
Now, as a developer, I’ll look at the project’s Issue tracker to see what I need to work on. I see there’s an issue here, let’s click on it.
It’s asking to change some text; seems pretty straightforward. And look at that, there’s a proposed merge request already. Let’s take a look at that. Here we can see the exact code that has changed and discuss it. But I don’t just want to trust reading the code, I want to see it live. Let’s go back to the project and we see a link to the staging server where this merge request has already been deployed.
Now this is great, I can see the change running live, but I realize I’m not really happy with that. Let’s make another change.
From merge request, view Changes, then press Edit
Change line 48 to "Welcome (insert name or person or company)" (Important, change line 48, not line 4)
Now that we’ve made a change, it kicks off a bunch of automated processes to build, test, and deploy that change. Let’s follow the progress. [Refresh until Builds tab reappears, then click on it]
The first step is to make sure all the unit tests pass on GitLab CI. [Example]
Now that that’s finished, it goes on to build the docker image and push it up to the integrated GitLab Container Registry.
The docker build can take a while, so in the meantime, let’s take a look at the container registry where you can see there’s already a bunch of images, including a couple special tags for
Back to CI, if the build succeeds, we take the docker image and deploy the application using Docker Cloud. Docker Cloud is set up to grab the image directly from GitLab Container Registry and deploy it.
Anyone reviewing the code can now go to the staging environment and see those changes live.
We can also go to the Pipelines tab and see the history of CI build pipelines, and if there are any failures, it’ll quickly show you the stage where any builds fail.
And on the Environments tab, you can see what’s currently running in staging and production. This clearly shows that while my new changes have made it to staging, they haven’t made it to production yet.
Since we’re happy with the changes, let’s ship them to production! Going back to the merge request, we’ll click the Accept Merge Request button to merge the changes into the master branch, which is configured to automatically deploy the application to production. Back on the Pipelines tab, we see that we’re re-running CI on
master to make sure the tests still pass after the merge.
While we’re waiting, let’s go back to Environments. Clicking through on
production, we see a history of everything that has been deployed to production. This is great to see what exactly has been deployed, and also exactly when changes were deployed. There’s also an easy way to rollback to one of the previous deploys. That can be a life-saver in an emergency so you don’t have to wait to write a hotfix, wait for it to be tested again, etc.
Now that everything is updated and our fix is deployed, we can now go to our website and verify that the fix is indeed deployed. If we want, we can also go to the Container Registry to see that the production image has been updated.