Okay, so we've got ourselves a problem in production.
And when it comes to troubleshooting problems in production, this is the worst possible position to
be in.
Ideally, we'd like these things to happen in development and not just appear in production because
it's much easier to troubleshoot and solve problems in development.
If we have something like this on production, then it's normally really, really tricky to troubleshoot.
So what I want to do is I think I know what the issue with this is.
And in fact, a Google search will get us to a Stack Overflow post that will tell us pretty quickly
what this is.
I should think, and if I just paste that into Google, then inside Stack Overflow.
We're not the first to come across this.
And if we take a look inside here, a different technology.
It's using Vue instead of react.
But same kind of deal.
They've got the key being passed as an environment variable.
And if we take a look down here in the solutions then the issue is solved by typecasting the key to
a string.
When it's getting it from our environment variables, it's not specifying it as a string, it's something
else.
And by putting it in backticks, then that forces it to be a string.
Why we don't get this in development or it's only just appeared now is something I do not know, but
it has.
But anyway, that looks to be what the issue is, and a simple Google search pretty much tells us what
we need to do to fix this.
But what if it's not something that's so simple to Google and say, hey, what's the problem with this?
What if it's something else?
Well, I do want to double check and just go through the options we have with Azure, because troubleshooting
a production application in the cloud is tricky.
So inside our app service we do have the option to diagnose and solve problems.
Let's just click on this first of all.
And there are tools inside here that can help, but the one that I would typically go for straight away
is the application event logs.
And if you click on this, then this will give you the event logs as though you're running on a windows
machine.
And if you had a net error then the exception would be outputs into.
Here we're not working with a net error.
So all I've got is info inside here on the logs.
But if you did have a net error then please come to this section.
This is the equivalent of having an exception in development.
And taking a look at the API logs.
The exceptions are going to be output into here.
And you would see the errors.
And then if you select it then below you'll see the details about the error the same as you would see
them in the net terminal.
Obviously that's not going to help us with what we're doing here, but I would encourage you to take
a look at this.
Other things like database connectivity issues.
They're all typically resolved by fixing the connection string.
That's typically the issue with that side of things.
So also double check your environment variables as well and make sure they're accurate.
Because one big difference between what we did by right clicking publish folder and deploying compared
to what we're doing with the workflow deployment, is the workflow is relying on the code that we have
inside our GitHub repository.
Now, anything that we've ignored from GitHub and thinking about it now, I've thought about it a bit
more.
That is the problem.
And in fact, casting that to a string isn't going to solve that problem either.
Because if I go back to the code and I take a look at what we're doing here, we've got our env file
and our env production file, these are both dimmed out.
So it's actually not an issue with casting this to a string at all.
This is absolutely fine.
But because this is not going up to GitHub, then we're not sending up our key with this.
So how do we resolve this then?
Well, we actually do need our production key to be in our GitHub repository if we want continuous integration
to work.
So where I've got the env production being excluded from GitHub, I actually need to make this available
to GitHub.
So I'll go back to the let's see how can I just do it from here?
I don't think I can.
I think I'm going to need to go to the git ignore file.
And let's scroll down inside here and find where we've got the env production excluded.
It should be added at the bottom because that's one we added manually.
And I'm going to remove this from the git ignore file.
And we're going to send that up with our git repository code.
And then this will be able to be used when we build our react application.
And it should solve that problem.
So not that tricky to resolve I think.
Well I actually am going to touch word cross fingers and use my lucky rabbit's foot because now I've
said it out loud, it's never going to work first time, but let's give that a go.
So currently I don't even have my catalog loading.
And my presumption is that that's related to the stripe API key being missing from our react application.
So back to version control tab and a couple of changes in here.
I'm going to need to stage these changes.
And I'll just give it a commit message of git ignore updated.
And I'll commit this and I'll sync changes with GitHub.
Now what this means is we're going to have to wait for the workflow to do its thing all over again.
Now, in my case, that took about 3 or 4 minutes to build both the react application and the.
Net application.
So now's a good time to get that cup of tea or coffee that you've been thinking about as.
Or I'll just make sure it's actually started first before I go and do that myself.
But we can see that our workflow is indeed running.
So this may take a minute or two.
So I'll pause the video and come back once it has completed.
Okay, so that did complete successfully five minutes 43 seconds.
That is quite time consuming to deploy our application, but it's not something that we need to keep
an eye on.
Once we commit our changes, we can normally be typically confident after it's worked 1 or 2 times,
it's going to continue to work in the background, and it's not something that we need to have our eyeballs
on as it's going on.
But did this solve the problem?
Let's go back to the application, the published application, and let's try refreshing the page and
see if we get progress.
And sure, the catalog is now back and I can presume that that API key was the problem.
So just a reminder really, that when we do use a GitHub workflow to deploy our code, it does rely
on the code that we have in our GitHub repository and not the code that we have inside VSCode so much.
And anything that we exclude from git ignore is also excluded from our deployment.
It doesn't matter about the app settings or the app settings development.
Jason, which is not used when we're making a production dotnet application because we supply those
values directly to Azure using the environment variables that we've already looked at.
So let's go and take a look and see if our application actually has been updated.
So I'll go to Bob's orders.
Click on my orders.
Click on the order.
And what we should see now is that the code change that we were expecting to be implemented has indeed
been implemented, because now I can see that my three snowboards now amounts to 600 instead of 200.
There.
So I'm fairly confident that the code change has been deployed.
But let's go and take a look at creating another order with a payment failed card.
And I'll just add let's see.
Let's just add a cheap product into the cart just to make sure the delivery fee stuff works as well.
I'll go to the basket, I'll go to the checkout and we've got the address that we saved earlier.
Great.
That's good.
I'll click next and I'll go and find a stripe test card and I'll get one of the declined options or
I'll use 3D secure I think this time in fact.
So I'll get the 3D secure authentication and I'll choose the one that says Always Authenticate.
I'll go back to the app, I'll paste that card number in, I'll give it an expiry date in the future.
Give it a security code.
And I've got something else new that's come up now.
And this is something else that again stripe is enabled by default.
And I don't want to use the one click checkout with link.
It's something that needs to be signed up for.
Not something we're going to do.
It's actually caught me by surprise.
Again, stripe.
They continue to add things in that I'm not using in this training course.
Again, this is something else that you can disable in the payment methods that I looked at earlier.
I'm going to ignore it for now.
We don't need this for what we're doing.
So I'm just going to click on next.
And I'll get taken to the billing and delivery information.
And I'll click on pay.
And this should bring up the prompts.
And on this occasion I'm going to click fail.
And we should get taken back.
And we see the toast okay.
And what should have happened is that we've got a new order.
And if we take a look at the orders we get, the payment failed.
That's what we'd expect to see there.
So I'll go back to the baskets and I'll need to go through the checkout again and click next and paste
in the card number expiry dates in the future and give it a security code.
I'll ignore the link pay thing, click next and I'll click pay.
And this time I will complete the payment and we get taken to our success page.
But what should happen now?
If I go to my orders?
Then we briefly see the loading indicator, but now we see that that's been updated to payment received
and that's what we're looking for here.
So that's the final action in this section.
We've now got our application deployed onto the internet.
And we've set up continuous integration as well.
And we're looking good.
So we don't need to commit to any more code changes into GitHub.
Obviously we've been doing that as we've gone along.
And we'll wrap up this section with a summary.