In this short video, we’re going to take a look at what a traditional DevOps stack looks like. And, what that means for teams to stand up a new project and get CICD working. Additionally, we’ll discover how that contrasts with GitLab and our vision for complete DevOps.
We recommend watching the video for the best experience and to easily follow on screen references. alternatively, you can read the video transcript below.
DevOps vs New Projects
So, here we look at the legacy state set of tools that many enterprises use for DevOps. Firstly, let’s talk about a brand new project that’s getting started by a developer. Initially, they’ll have code and start creating this new project. And of course, the developer is going to be uploading that to their source code source control management system. For example, GitHub Enterprise. So we’ll need a new project there.
Creating Access In New Projects
And, to ensure the right people are credentialed and have access to that project. Next. we might hand off that project to the infrastructure and DevOps team. They’re going to create a new channel in Slack to help with ideation. They’ll create a new project with the right credentials again, matched up in JIRA, so that we can manage the planning of this project. Then, they’ll create a new project or folder in Jenkins, making sure it has the right credentials to connect back to source control. Following on from that, in the DevOps side of the house, we might make a new project. Or, perhaps write prod files for Puppet and Chef to stand up environments for this. Furthermore, maybe we include those in source control, maybe we don’t. It depends on our processes. Then for production, we’re going to have to stand up a new instance. So, I have to spec that instance, let’s say an AWS or Nettie’s. But, it doesn’t stop there because I’ll have to create that instance and ensure the credentials that get all the way back are ready for that instance. And then maybe create a new project in New Relic. For example to monitor that production instance.
Completing The Project Setup
But then also, if we want to Dockerize and kind of take this into the cloud, we’re going to have to create a Dockerfile. And maybe a Docker Hub to store that, or have an artifact store like Nexus or Artifactory. Following on, we’re going to connect the build process into that channel in Slack we created. That means we can actually have build statuses visible by the developers. Then there’s artifacts, or those Docker images – we’re going to want to factor those into our Puppet and CHEF scripts.
Now, we’re also going to want to focus on code quality. So, probably at build time, Jenkins will push code quality metrics to Sonar. Then we might want to connect that again back to Slack to understand how code quality is changing as we make changes. And then, you know, we’re going to want to again put the monitoring in the Slack so production issues are clearly noted back to developers.
The Overarching Challenge
So this is, approximately 20-plus steps to set up, connect and wire together this brittle architecture. And, in many organizations, this can take a long period of time.
And, it could involve multiple roles. For example, if someone manages JIRA, someone manages source control, someone else makes Jenkins and someone else manages production environments. Now we’re talking about multiple roles involved. And, they’re shared time, and you know when their availability is to stand up something new.
Utilizing GitLab For Project Configuration
So this contrasts with GitLab in a mature state, GitLab controls everything about our software delivery pipeline, and maybe it’s still connected to Slack because we want to do some chat ops. But, the developed code goes right into GitLab. From there, GitLab automatically detects what kind of it is builds it. And, it automatically:
- Uses Heroku build packs for testing and code quality.
- Dockerise’s the app for us.
- Deploys it into a Kubernetes cluster with auto review apps and auto deploy. And, because it’s deployed in Kubernetes and we have prometheus baked in the gate lab were automatically monitoring that code. From day one.
So, in this way developers are able to deliver code faster to production. And it cuts out that brittle house of cards traditional DevOps stack.
Ready To Break Your DevOps Daisy Chain?
If you would like support with GitLab, or breaking your DevOps daisy chain, contact our team here. We’ve been in business for over 20 years and supported DevOps teams globally to adopt more efficient ways of working,
