Demo video for Auto DevOps
We want to have a demo video for Auto/Integrated DevOps (gitlab-org/gitlab-ce#35712) that can be used once we'll release the first iteration in GitLab 10.0.
It could also include other features that are valuable and that were not included in previous demos. It is something different from our I2P demo that will continue to work as usual, as it has very specific properties and use cases.
This is the evolution of #1452 (closed), that is an early preview of our vision, and can be used in many scenarions:
- GitLab 10.0 release post
- GitLab website
- Specific blog post about Auto/Integrated DevOps
- Marketing
- Meetings with customers
This is the actual script for the demo (still WIP):
- Clone the example project locally and "ungit" it (off camera)
git clone git@gitlab.com:auto-devops-examples/minimal-ruby-app.git
rm -rf minimal-ruby-app/.git
- Create an empty project,
minimal-ruby-app
- Enable Auto DevOps in project settings
- Mention instance-level default
- Show project-level Kubernetes and Prometheus configurations, just for awareness. (mentioning that they're already set up for me because the instance is configured this way, but you might have to set them up for each project)
- Follow Command line instructions page for Existing folder
cd minimal-ruby-app
git init
git remote add origin git@gitlab.com:user/minimal-ruby-app.git
git add .
git commit -m "Initial commit"
git push -u origin master
- Improve homepage (add HTML and remove comment), create MR at same time
<h1>GitLab 10!</h1>
- Show jobs for: Auto Build, Auto Test, Auto Code Quality, Auto Review App
- Show Auto Review App, live version
- Show enhanced code quality
- Merge into
master
- Show pipeline, including job for Auto Deploy to production
- Scale deployment to 5 pods (setting secret variable
PRODUCTION_REPLICAS
) and re-deploying - Show Auto Monitor
- Click on Set up CI, pick Auto DevOps template, add staging and canary jobs (by removing the leading
.
in the job name, make production job manual (uncomment thewhen: manual
line), commit tomaster
- Show pipeline with new jobs for Staging and Canary
- Show deployment to staging and live version
- Manually deploy to canary,
live version with live different responses - Manually deploy to production, live version
Demo project is https://gitlab.com/auto-devops-examples/minimal-ruby-app. (although I ended up using some variant of this)
Final words:
GitLab 10 Auto DevOps Demo Video
Hi, I’m Mark Pundsack, head of product at GitLab, and I’m going to show off one of the great new features of GitLab 10 called Auto DevOps.
Actually, Auto DevOps is a collection of 6 features:
- Auto Build
- Auto Test
- Auto Code Quality
- Auto Review App
- Auto Deploy, and
- Auto Monitoring
These 6 features not only work seamlessly together, but to work together automatically, with almost no configuration. We think that’s the best way to bring these best practices to all of our developers.
The best way to show Auto DevOps is to show it in action.
I’m starting off with a new installation of GitLab 10.0, and I’m going to create a new project. This one will be just a minimal ruby app.
Before I do anything with it, I’m going to go to the settings and enable the new feature, Auto DevOps. It’s just a single click, enter in your base domain, and save. Now, if you’re administering your own GitLab instance, you can actually enable Auto DevOps for everyone in your organization in the admin settings, and that would change the instance default, which here is still turned off.
While I’m looking at settings, I’ll show a couple things that have already been configured for this instance.
The first one is the Kubernetes service, which allows me to connect to the underlying Kubernetes platform for deployments. And the other is the Prometheus service which lets me connect to monitoring metrics.
These were both enabled automatically because I installed GitLab using our new Kubernetes Helm chart, but for others, you might need to set these up yourselves.
So now, back to the project, it’s still empty, so GitLab gives me some instructions to get started. I already have a simple app locally, so I’ll copy the appropriate instructions.
Then paste them into my terminal, and you can see it checked all of my code into a new git repo and pushed it up to GitLab.
Back at GitLab, I see my new code there. Note there’s nothing special about this app, it’s just a little Ruby application, no CI/CD configuration, not even a Dockerfile. Just a server.rb, saying Hello World.
Let’s go ahead and make a change. We’ll remove the TODO comment, and go ahead and add a nice header. Then I’ll save it to a new branch, and create a merge request.
And now the exciting stuff, we see it kicked off a CI/CD pipeline for us. Remember, I didn’t actually configure any CI/CD for this project at all, this is all Auto DevOps kicking in.
So here we see a pipeline with a few jobs. Here’s it’s running Auto Build. If you have nothing specified, it’ll use Heroku buildpacks to detect your language and build an appropriate Docker image. If the project had a Dockerfile, it would have used that to build instead.
With the build successful, it kicks off Auto Test. Again it’s using Heroku buildpacks specific to the language so it knows how to test the app.
It also runs a job to do static analysis for Auto Code Quality.
And when all that looks good, it automatically creates a review app by deploying the app to Kubernetes for me. Here we see a bunch of steps it’s doing automatically for us with the highlight being a deployment to Kubernetes, using our default Helm chart. If the app had a Helm chart in the project itself, it would have used that custom chart instead. Or I can even add a project variable to point to another chart. But here, we’re using the default.
To see the beauty of the review app, let’s go back to the merge request.
Here we see a new line showing us that it was deployed to the review app, and here’s the URL to actually see my change running live.
And there’s a line for the code quality. We see here that it likes that we removed the TODO. If we made things worse, it would show up here as well.
This all looks good, so I’ll go ahead and merge. Now we see it’s kicked off a new pipeline. And inside this pipeline, it looks familiar, but a little different. Instead of creating a review app, this one is deploying right into production. This is continuous deployment at its best.
Going to the Environments, I see production listed here, and I can easily click through to see what it looks like.
Now, there’s more to this page. Expanding the environment, I can see the status of the last deployment. In this case, it’s just a single pod. Let’s go and scale that up. I’ll go to CI/CD settings and add a project variable to set the PRODUCTION REPLICAS to 5.
Now let’s go back. And I can redeploy. Soon we’ll see the deploy board update, and we can wait a bit to see the deploy finish. With Auto Deploy to Kubernetes, you have visibility into your deployment.
That’s pretty cool, but wait, there’s more. This little graph icon leads us to graphs where Auto Monitoring is showing us the performance of our production app. Again, I didn’t configure a thing here, all the metrics were detected automatically. We’ve got latency, and error rate, and down here is throughput.
So that covers Auto DevOps from build, test, code quality, review app, deploy to production, and monitoring. Pretty awesome. But what if you want to do something differently?
Well, here I’ll go to manually set up CI, but instead of having to start from scratch and re-create all that we just saw, I can pick Auto DevOps from the templates, and import the whole thing. There’s a lot in here, but it’s not as scary as it first looks.
And there’s some helpful tips in here already. Say I’m not ready for continuous deployment to production, I can just uncomment out this staging job. And if I want to add canary deployments, I uncomment this one. I then just need to uncomment this one last line to make my deployments to production manual and I’m ready to go.
So I save this into master. And now I see another pipeline is kicked off. This one again looks familiar, but there are two new stages for staging and canary.
Now I just wait for staging to deploy. There, now we can go back to environments, and now I see I’ve got a new staging environment. Again, it’s going to be running the latest changes automatically. And when I’m ready to move that the canary, I can just click right here, and it automatically deploys to the canary. And I can even see my canary deployment happening in the deploy board!
With that finished, I can go ahead and promote to production.
Great, now it’s in production!
So whether you want continuous deployment to production, or a continuous delivery flow that’s more under your control, or even if you want something else altogether, we’ve got you covered.
That’s Auto DevOps, the fastest way from Idea to Production, and it’s new, now in beta, with GitLab 10.0.
Video: https://youtu.be/AgKc_KUQEtE