Commit fbcf5d0c authored by Rebecca Dodd's avatar Rebecca Dodd 🗽

Copy edits and update Twitter pic

parent da7a7cfd
Pipeline #12028516 passed with stages
in 25 minutes and 23 seconds
......@@ -5,7 +5,7 @@ author_gitlab: markpundsack
author_twitter: MarkPundsack
categories: GitLab
image_title: '/images/blogimages/devops-nova-scotia-cover.jpg'
twitter_image: '/images/tweets/devops-strategy.png'
twitter_image: '/images/tweets/devops-strategy-tweet.png'
description: "How we're building GitLab into the complete DevOps toolchain."
---
......@@ -24,6 +24,7 @@ issue for [GitLab DevOps](https://gitlab.com/gitlab-org/gitlab-ce/issues/32639).
<iframe width="560" height="315" src="https://www.youtube.com/embed/zMAB42g4MPI" frameborder="0" allowfullscreen></iframe>
## CI/CD: Where we've come from
![CI/CD/Beyond CD](/images/blogimages/devops-strategy-ci-scope.svg)
......@@ -40,7 +41,7 @@ stuff; to show how the pieces fit together into a development lifecycle.
![Example pipeline](/images/blogimages/devops-strategy-example-pipeline.png){: .shadow}
I love this diagram not only because it's complex and scary, but because when we
started, we had maybe 4 boxes filled in, and now we have 10 or 12 filled in. To
started, we had maybe four boxes filled in, and now we have 10 or 12 filled in. To
start with, we had code management and, obviously, builds and tests. And we kind
of did deployment, but not really.
......@@ -64,7 +65,7 @@ So we've gone from a core view of three or four boxes to where 90 percent is
complete. That's pretty awesome.
It became obvious to me that we were viewing the scope with this hard line:
developer-focused rather than an ops-focused. e.g. We’ll deploy into production,
developer-focused rather than an ops-focused. For example, we’ll deploy into production,
and we might even watch the metrics related to your code in production, but
we’re not going to monitor your entire production app, because that’s
operations, and that’s clearly out of scope, right?
......@@ -203,7 +204,7 @@ thing.
The idea is to take the same application, and instead of just looking at a list of environments, I’d be looking at columns with lots of review apps, and some number of staging environments, and a production environment. Instead of just showing you the SHA, we would show you, for example, what merge requests have been merged into staging that are not yet in production. That’s a great marriage, of these two views, that you’d be able to see the diff between them.
This list, although, it’s just a mockup, shows maybe the last five things that were in production, or what was included in the last deploy, or whatever it is, whatever works best for your environment. So, showing what’s in the last deploy might be enough, but for people who deploy 17 times a day, maybe that’s a little less useful, and we just show history.
This list, although it’s just a mockup, shows maybe the last five things that were in production, or what was included in the last deploy, or whatever it is, whatever works best for your environment. So, showing what’s in the last deploy might be enough, but for people who deploy 17 times a day, maybe that’s a little less useful, and we just show history.
But then what about building in more of the operations kind of stuff, and say, “Alright, what’s the state of my pods?” Here we were flagging one, where the error rate exceeded… there’s some alert that popped up. And here we’re showing this automatic rollback kind of stuff, but basically just really building in this ops view. Of course this is still a DevOps view, in the sense that I’m looking at an individual project. So, one permutation of that would marry that ops view of all of production. Or if I’m looking at a microservices kind of thing, where there are five or 100 different projects, and I want to see the status of all those really quickly.
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment