The next step in the process would be to use the IWC ally to deploy this new version that we have just
uploaded and unfortunately, this is not as easy as copying a file from one side to the other.
I need to explain a few things in order to deploy to IWC Elastic Bienstock, we need to do two things.
First of all, we need to create a new application version.
And second of all, we need to update the environment.
Let me quickly remind you what these terms mean.
One application is called API, and we have created an environment called production later we'll have
other environments as well.
Now for this environment production, we have a running version.
You will see this is a sample application.
One doesn't really matter just to keep in mind that there are different versions.
This is why we need to make these two steps to create an application version and then to update the
environment with the application version that we have just created.
Going back to our pipeline configuration, there are a few things that we can improve.
Now, you have noticed that we have used the artifact name here and again here and here.
So every time we start duplicating things in our configuration, it's always a good idea to think about
using a variable.
This is exactly what we're going to do next.
I'm going to copy this name.
And before stages, I'm going to define variables.
And the first variable, I'll call it artifact name, because this will be the name of our artifact.
And everywhere where the artifact cars appeared, that car was present, I'm going to replace it with
this variable.
Because previously I have mentioned versions, it would really make sense to give this artifact name
sort of like a variable name instead in the sense that it should contain a version as well.
If you remember, it comes with a huge list of prettified environment variables.
And one of these variables is SII, underscore pipeline, underscore idee.
Now, there are at least two options of these you can use to underscore on this caller ID, and this
will be an unique I.D. to the current pipeline that Gottleib uses internally.
And the other one, which I d is unique I.D. that it's coalbed to the project.
So I'm going to take a look at this and see how that goes.
Of course, you are free to use any environment variable that you feel that matches your need.
This will be a simple idea that will be incremental, at least not directly incremental, but it will
be larger than the previous one.
So this will tell you if a version is newer or older than the previous version.
In this day and age, keeping track of versions as we used to do in terms of semantic versioning like
version one, version two, version three and so on, it's not really a requirement anymore.
And simply having a unique idea which can help you identify which version of the project is deployed
on the server, it's still good enough in order to get Destrehan.
So I'm going to call that this is fresh and in this core idea, that's what you do with a WASC ally
and see how we can deploy this.
Now, as I mentioned, the first step is to create application version.
So this goes like a WSC Elastic Bienstock create application version with dashes between the.
An experiment that we need to provide is application name.
Because our obligation is cast API, it would make sense to put this in an environment variable as well.
Initially, we're going to give our version label sort of like a back to this version that we can easily
identified because we're already using a variable from Getler, we're going to use the same variable
that we have used for version.
Now finally comes the part where we reference what we have updated in our S3 bucket and practically
a W.S. Elastic Bienstock, hey, take this artifact, take this file that we have and use this in order
to create this application version than the instructions for this will be this dash source.
Dash bundle.
And this will be S3 Buckett.
And then to give the variable that we have used for the S3 bucket.
And he saw the identifier for what you are trying to upload will be the S3, he.
This will be the artifact name.
So it is command, it will know to get this information from the S3 Buckett, which has this S3 Ketso,
get the object old what we have called it, Khazei Peja, when the specific version and create the new
version we did.
Now, this in itself will not change what is being deployed.
What is currently executed on the production side of it will just create a new version, but that version
will not be active.
So for that reason we need to execute.
Another command in this command is called a W.S. That's the Bienstock.
Update environment.
The application name will be the same.
The environment name will be production.
And finally, we have again, diversion label, but we can see that a few informations are still similar
to the previous one because we need to have a relationship between what have we created for an application
version and what do we want to actually deploy.
Because what update environment will do is we'll take this version that we have uploaded, practically
deployed, make it live.
OK, so I don't think the label needs to be equal here.
And finally, in the big process, there's still a small change that we need to do so far we have assumed
that artifact will be called that Daija, and this is how the artifact will be built.
But it doesn't mean that we can keep it this way because now we have a variable name and we need to
rename the artifact as well.
So in order to rename that, we're going to use the move command and we're going to do is to move the
file from built lips, car dash API, Daija to build lips.
And then this will be the artifact.
This is hardcoded in the project.
So this is why this has to stay this way.
And we still need this extra step to commit and see how the deployment goes.