come back. This is less than 4.2. We're gonna be talking about pipeline orchestration,
and this is gonna be getting a several different topics and concepts they're gonna bring in here. I just wanna get set the stage
sofas. Lesson objectives One discussed the major steps in the
continues integration continuous delivery.
Explain how security failures air Jugic ated. Some, like talk about the strength of orchestration pipelines and organize them. The tools for the for this orchestrations. Well,
so first I idea is development. We have talked about this a couple times, but what does it actually mean? It's combining coding and the building. There's these air to dis distinct activities. There's some overlapping tools.
Development is actually taking when you're writing, the code is converting requirements into code. It's done a lot of times or most that should be done in an I D. And then the source code is stored in a repository, whether it's get lab, get hub, whatever local repository or cloud based one they're using,
the what a source code mean. It's It's part of the application. It could be infrastructures, a code which will talk about a little bit later. The test scripts to. The idea is to everything that's used to create. The application should be in one repository
by build, we mean is taking packaging the application or these micro services, if that's what you're using. So, for example, in Java that means creating by code, then turning at byte code into a jar with single application or war file, like we've seen if it's a Web application.
But this also includes interpreted code, it doesn't have to be compiled like Java script, python any of that. So that should get package and deployed in the application
where it's gonna finally reside
since, and they should all be triggered by orchestration. So we've seen this kind of go through this pipeline. I already have. The Jenkins already have the source code sitting there really wouldn't. You don't want a human sit in there pushing buttons. What it would be is you'd have the repository. And whenever a developer or anybody pushes out some new code
that would actually trigger the built sequence so that it's completely automated. You know, having humans trying to push buttons
just again, jump in and give you a chance to think
what does the distinction between development and build
So development is the activities of actually creating the code again, like we mentioned, taking requirements of what the APP looks like? Or fixing issues and turning that into code or fixing code,
whereas the build takes that code or those objects and that that that information and putting it into the final application award again the actual or if we're talking about infrastructure code, actually, creating the architecture and setting up the pieces that need to be there to deploy the application
have a good graphic here that get lab put together that I like. This was kind of showing you how a zai mentioned up in the top left. You have the repository. When code is committed, it actually kicks off this continuous integration,
which then runs the review of the APP.
Some of the static analysis may be wrong on this, and you'll we'll see this kind of static analysis done in our Jenkins a demo
and then any findings that that are
that arise out of the static analysis get created as issues and then they get assigned to a developers, developers has to do. You have to adjudicate them, and you continue running this cycle until all the issues are adjudicated. And once that's done, the code and gets merged into the continuous delivery and then the same type of a review special for security would be
the security. And our analysts would then look at this.
These issues see if they're duplicated correctly before they get and they get resolved in once
they are, then it gets deployed.
And we can show this as people here. If you have it set up and completely automated, you could you could set up with the exit criteria so that you could you would accept certain thresholds and he's
there would be no humans in a way, and this code could be continuously delivered.
So the idea of Def SEC ops orchestration that we have, ah, orchestrator again for this module or them? It's this whole class were using Jenkins, but there's a Derby s as codepipeline. They call it Azure. As pipelines.
There's actually, once you get any operation side, there's kubernetes for orchestrating containers. There's a whole lot of different topics idea of the orchestration and have lots of tools out there
for the pipeline. We've mentioned it before, but it is. You have stages and there's conditions and the exit rules for each one of those stages before the the build is considered a success. And if do it doesn't mean the extra criteria. It stops right there and nothing gets deployed
or it doesn't even go any further.
So what did you bring up this concept of? Well, this is, ah, image from the enterprise D o d enterprise deficit cops reference design. But we've talked about each one of these or this bill processing the stage as these linear single development efforts in
a more complicated environment are much more complicated application, especially if you have micro services. You might have different teams building on it so you might have these different pipelines, so each one of them will be working separately, creating code and merging it into a single repository. So just
kind of expand your mind a little bit and think of it as
as more than just one team and integrating all these things working pieces.
Here's a quiz. Which of the following is not used for pipeline orchestration?
aws codepipeline *** era?
We haven't talked about this yet, but you may have heard this thing Software before it's Ajira is actually a code management tool for a scrum boards roadmaps issue tracking things like that. It's more of a collaboration tool. It's not meant for pipeline orchestration. It's It's an important kind or important component, but it's just not done for the orchestration.
So we talked about orchestrating security into Dev ops and a lot of the concept that that we just need to kind of understand. So as we work through this world, these aren't any new words or terminology that we're bringing up.
Next will work on static analysis after development.