This lecture, we're going to take a look at how we can use the anchors from the Yamal language and
apply that information to our digital IPSI pipeline.
Now, if we take a closer look at our pipeline, we will see that we have a few jobs that aren't, in
essence, quite similar.
And from all jobs that we have deployed, job is more or less duplicated.
So from all the jobs that we have, the deployed job, we have three instances.
So we are deploying to the review server, we are deploying to the staging and we're deploying to production.
And even if we simply compare, deploy staging and deploy production, we'll see that they are very,
very similar.
So what you will do is to try to find like what's similar in all this jobs and to extract that information
to make the job much simpler.
In this example.
That application isn't that bad, but.
In other more complex project, you can end up with job definitions, which are very similar, very
long, and it doesn't make a lot of sense to make a change all over just because something is change.
So let's try to extract specific information.
So we'll do the following.
Let's try and see if we can define a template.
I'm going to call it deploy.
This comtemplate.
You won't see that by using the dot before it, this is disabled, so this will not be taken into consideration
by Guillem.
Now, let's take a look at both and see, which is similar to, for example, we have here this only
configuration, which for both is the same.
So we can start moving that.
Additionally, if we look at a script itself, we'll see that that is pretty similar as well.
There's only a small difference.
This is using staging domain and this is using production domain.
But I'm pretty sure that will be able to find a way around this.
So I got to move this year.
And instead of staging domain or production domain, let's just simply call it domain.
Now, there's one more thing that we still need to do, first of all, we need to find a way to define
these variables.
So let's go here, create a variable configuration.
And when we find a variable domain.
And in this case, in the case of staging to take the value from staging domain.
And if we look at production, we can use.
Reduction.
And if we go one step further and replace.
This information from here, from the environment, we can see that even the environment is not that
different.
So let's copy the environment as well.
Because we want to remove this key from here, because this is something that we cannot know.
But apart from that, looks pretty good now in order to use this template inside our job configurations,
we need to refer to this anchor and we haven't defined an anchor yet.
So let's define this anchor.
Let's call it deploy.
And in order to use the anchor.
We're going to use it like that, and what this will do is to march this new configuration into one.
But this is for the police.
This is for.
Deploy production.
The next step will be to take this configuration that we have here and try to validate it.
So I'm going to select it and I'm going to copy it.
Now, I'm here at krp, at my project, and I'm going to go from the left menu to secede.
Right here on top, you should notice a button called Silent.
This tool helps us verify our catalepsy lapse YAML file, and this is especially useful if something
doesn't work or before committing, if we are not sure that what we have done there is actually valid.
Well, A simply pays the content here and a click on Validate.
You will see that I will have an error saying Syntex is incorrect and will say a specific error, and
that's quite helpful because I can then have a look at the line that is being indicated 102.
And I'll be able to see that in this case, I haven't I don't have the right indentation for variables,
so this is not correct.
So if I make now the correct indentation, let's see if it works.
And it says Syntex is correct.
Not what I actually wanted to see if this configuration, if this template that we have used here has
been properly picked up.
So if we take a look at the deploy staging job, we should see a couple of things which would see that
only master has been set.
The script has been said.
So let's go to deploy staging.
Now, what this does is list all the jobs that are here and it explains what Gottleib has understood
from this.
So this is the staging.
You will see here that we still have NPM install installing surge.
This is actually a display problem that Gottleib is having.
This is the other command that we have where we are actually deploying to search.
So at least from what we see here, it seems to be working properly and this configuration has been
correctly being picked up.
So I'm confident now that I can commit it.
And let's see, it's on in action.
I have now created a request and I have merged that specific branch and now the pipeline for Master
has been started and completed successfully.
Now I can see that the staging and production work without any issues.
And if I'm just interested in seeing if everything actually worked well, I can simply go inside a job
and see that all the steps and all the stages, as they were before, have been used, that the proper
domain name has been used and that everything has been properly deployed.
So using this technique, you can go ahead and do the next step on your own, so we have defined this
template deploy template and we have used it for the staging and deployed production actually deploy
review is quite similar.
And I wanted to give you the opportunity to try it on your own so that you can get some real world experience
on adapting this to make sure that all the deploy stages now use this template.
And as you have seen, even this configuration is pretty simple.
It is nice now to have a central way where you can optimize or change this code without having to update
each and every of these environments or each of these jobs that you have there.