As part of the deployment process, we want to make sure that the version that we have built and deployed
is actually available in production, and because we want to automate things, we don't want to go to
the console to see old version seven is running.
We want to find a different way on how to do that.
If you open Posman again and select the production environment, you'll be able to manually test the
application.
The first thing that we're interested in is to check if the health status is up.
So if the application itself reports that everything is OK.
Additionally, there's an informal point that can give us additional information.
Now currently is not populated with any data, but whether we can do is to replace this information
here with actual data during the process and then when the application is deployed, will be able to
ask the application, hey, tell me, which version are you currently in?
And if the application reports, hey, now I'm version seven and we will know that application that
we have built is now actually alive.
So we will not have to only rely on a table worth reporting and saying, hey, I have the Buddhist,
trust me.
So we'll have an additional way on how to check this.
Just in case you're wondering from where the variables are coming from, you can go to source main resources
and application Yamal.
This is where the application starts some information.
And one of those details is regarding the info.
And these are just placeholders here and we're going to replace them in our little FCI pipeline.
And we need to replace these variables before the actual build process has started.
So we're actually modifying the application that before the built.
So in order to achieve that, we're going to use said.
And the syntax for said was said minus I.
And then we'll specify what we want to search for in this case is the pipeline idea.
And this will be a string and we're going to replace this with an environment variable S.I Pipeline
Idy, and this will be the idea for the pipeline.
You can see I have named the placeholder exactly as the predefined lecci variable, but you can use
any name for the placeholder you like.
I just wanted to make it consistent and easy to understand.
And let's also add here slash at the end to make the syntax valid.
After that, we're going to get to pass through the application, Yamal, because we need to reference
which file this will be.
For that, I'm going to go here, copy path.
And the path that I'm interested in is from the repository route.
Just going to make sure that I get the local reference here and this should be fine, and I'm going
to duplicate this command for two other variables and I'm going to replace the variables there.
So this will be the commit committed.
Make sure to include a dollar sign and finally the branch.
So I'm going to commit this little pipe and run and then take a look in Bowsman.
And no enforcement after waiting for the deployment and keeping the production environment, and I'm
going to call the important point again and you will be able to see inside and point.
Now, the current version in my case, this is version nine is the committee that has generated this
version.
And now we are on the Masterbrand.
This is just some generic information.
Some of it will be relevant later, but it will help you identify which version is this?
Which committee has generated this version based on this information, we can later automate the process
and check this information.
Right.
And the deployment stage.