GitLab Feature Walkthroughs, 7 Mar 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: ATARC GitLab Pipeline Talk (preview)

Description

Links and materials:

Articles and examples at https://brownfield.dev
Trunk-based workflow from https://about.gitlab.com/solutions/gitlab-flow
Pie charts paraphrased from https://web.devopstopologies.com/#type-one
“Rich Change Control with GitLab” https://www.youtube.com/watch?v=uW95PV8d-w8&t=704

A

Hello and welcome to why won't anybody use our pipelines in this presentation I'm going to talk through a brief introduction. The concept of the pipeline, which many organizations end up, building two types of jobs, be creative jobs and compliance jobs and then I'll finish with aligning goals.

A

So the introduction Who am I I'm Mike, Terra I'm, a Technical Account Manager at gitlab I have 25 years of experience, doing all sorts of different jobs, I've done them for several different sectors. What are we talking about? Continuous integration pipelines, the struggles with DevOps and compliance old legacy, apps new things, best practices, how to do scalable, DevOps and all that stuff? How much of that we can talk about in the next 10 minutes, we'll see how we do so. This is how it starts.

A

Federal, devops team gets created. The DevOps team can't change anything about how anyone works, so they operate in between dev and ops. They use the waterfall processes that they're familiar with and they create a pipeline made of all the best practices as many tools as they need as many jobs as they want. It'll do everything as long as you follow all of their assumptions over time.

A

If this approach gets picked up, the dev ops team swells and becomes its own behemoth, it will take on the responsibility for the pipeline and then all of the ops aspects of that keeping it running and the dev aspects of it will fall into this team and the team will either grow if they have funding which is rare or they will struggle to keep up, won't be able to unboard new projects and that's the best-case scenario, because, what's more likely is nobody's using the pipeline because it's incompatible with the software and it doesn't deploy to any of the running operating models that are typically used.

A

So you're, stuck with a dwindling and ineffective DevOps team floating between dev and ops, I recommend the far superior alternative of collaboration where the ops team, the dev team, the dev ops team, are all playing with the same content but they're using it different ways. The dev ops team focuses on providing jobs instead of pipelines.

A

The devs are unable to use the sandbox and other environments to run review apps to run staging environments, to test things, to get information as early as possible on how they're building their code all those sorts of DevOps e goals and then on the ops side. The dev ops team focuses on providing high quality configuration management, hopefully convergent or congruent configuration where everything that's delivered from the dev team will be deployed into a safe, running, consistent repeatable, scalable infrastructure.

A

The best step to take in that direction is to split the pipeline into two different components: one is the developer pipeline or the creative pipeline. This one has the build unit test.

A

Code quality, all those skins that that help the the product owner make better decisions about what to merge into their master branch. This can include security testing, because that information is helpful. It allows bug avoidance rather than bug fixing you can have jobs that create the packages that compile the code or turn Java into byte code. Things like that create jars, wores, put those into containers and then run review apps.

A

This should all be totally under control of the developer if they need a different review app if they need a different backing service, if they have to add something about how its deployed they should have total control over the review app environment. The way the review apps are built, the number of containers, the sizes every aspect of that should be under the developer control unless they're doing something against policy. Of course, in which case there should be a discussion about. Do we change policy, or do we hold back this capability for a good reason?

A

On the other side of the fence, we have the compliance and enforcement pipeline. This is where security scans, maybe even the same exact security scans. That happen on the creative side happen, but the results aren't just informative. They are reviewed by security professionals, they're validated and then, if some change needs to be made, that change is sent back to the developers side to to get that change done to to make the code compliant with whatever the security scan requires additional tests. Things like functional testing, it can be manual, it can be automated.

A

You can have a job that just waits for an approval button to be pushed those those work, just fine, they can be protected so that you don't have other people who aren't allowed to push them pushing them and then, of course, the deployment job that actually manipulates the production environment. You want the production environment deployment lockdown so that it happens under the tightly controlled circumstances that it's supposed to have split projects.

A

The developer project has issues for planning the code spilt pipeline runs all the jobs creates all the artifacts builds the containers spins up the review, app dev environments and then see that arrow in the middle there. That's where the developer pipeline triggers the IV&V pipeline or the compliance and enforcement pipeline, and that one has infrastructure as code for deployment where you can run a check to make sure that the container that came in is the right kind. The right shape has the right ports exposed things like that. You can have automated functional tests in there.

A

You can have again the security scans that need to run for compliance manual, test cases and then finally, your manual deployment to production, and if you get a red X there where something fails, that creates a feedback loop which provides feedback to the developers.

A

The way that impact the developer workflow is minimally. If you have the entire developer workflow this most of the screenshot, with all the blue circles is from our get lab flow diagram of how we expect it to work. I don't have time to go into it, but right there at the end, you see the release.

A

Tag kicks off a cross project pipeline project pipeline can do all of these halting sorts of jobs outside of the developers workflow. So the developer can move on to the next issue. Keep building what they're building keep enhancing what they're built? What they're enhancing new features come out? Quicker security still gets done, tests still get done, deployments are done safely, so developers are empowered, they have the velocity, they have the quality, they can make their lives better. They can make the products better. They have compliance.

A

All those goals are met outside of the developer workflow, but still before the releases are done, and then you have all the work is visible.

A

If you follow a get lab, centric approach, the extra bonus there is if IV&V and ops have get projects, they can use those to automate their testing, they can automate environment deployments, they can automate manual testing, they can run selenium or Chrome web drivers and those sorts of tests directly through their review apps on the systems, so that the tests are more repeatable and faster and they can keep up more with the releases.

A

This was very brief and there are a lot more facets to this. You can read about articles and examples that I've come up with at brownfield dev. We also have trunk based workflow. We have pie, charts from DevOps topologies, calm, fantastic material there and then there's a rich change control with git lab video that I encourage folks watch if they want to learn more about how to use git, Labs built-in guardrails to do compliance thanks and I. Think I have no time for questions.