Adobe Commerce on cloud infrastructure - Deployment

Transcript

All right and unit four we’ll take a look at a Magento Cloud deployment.

There are a few different phases that happen during the deployment.

So, deployments, again, are started by pushing into the cloud provided GIT repository, pushing some code into that GIT repository on a branch that has a live environment attached to it. So, that’s what starts a deployment. And deployments can be anywhere from five to 20, 30 minutes depending on just how involved your deployment process is how big your store is, how many customers and products and so on. A lot of things can kind of extend the amount of time a deployment takes.

A deployment is sectioned into three different phases, a build phase, a deploy phase, and a post-deploy phase.

Taking a look at the build phase first.

During the build phase, the first thing that happens is that your cloud specific configuration files are checked just for syntax errors. They aren’t utilized at this point in the configuration but it is just checking for obvious syntax errors so that you don’t get 15 minutes into a deployment and then realize some white space is going to mess up your deployment. So, it’ll just kind of fail fast and tell you upfront if there are any problems with your configuration files.

Then it’s going to issue a composer install. So, your repositories don’t really have the Magento code base or any of the PHP dependencies until you issue that composer install command that brings them in from your composer.lock file.

At that point, you’re going to run the ECE Tools build script, which we saw in the magento.app.yaml file that this runs the majority of the commands, Magento specific commands associated with a build. So, for instance, set up DI compile would be run during that script and a bunch of other things as well. It’s a pretty robust script.

So, then at the end of a build phase, you basically what you’ve done during the build phase is you’ve taken what’s in your repository, which is usually the composer files and a lot of the cloud specific configuration files. And the point of the build phase is to just get every single file that is needed to run Magento, the Magento application at runtime. So, that’s all the core code files all the modules and everything and doing dependency injection generation that generates some code files, doing static content deployment generates some files. So, you’re just during the build phase attempting to get every single file that will be needed to run Magento generated and or downloaded from an external source.

Everything you need in one place and then at that point you’re going to kind of archive all of that and get ready to distribute it to whatever live web servers are going to run your store.

So, really important to point out the build phase is on a build server separate from your cloud environments. So, it is happening on a build server that all it does all day long is just build Magento, just run these DI compiles and everything else for many different projects. It’s a server that is just exclusively devoted to just building Magento.

Now, one of the interesting parts of that is at this phase, you don’t have access to any of the services that are available to your websites. So, it does not have access, for instance, to your database. So, you would not be able to do anything during the build phase as far as the customization. Nothing during the build phase could access the database. So, you just want to be aware of that limitation.

If something does need to access the database during your deployment, the deploy phase is the appropriate time for that. So, at this point, your files or your Magento application files have all been built during the build phase. They are then transferred onto your actual web servers. And at this point you do have access to the database or elastic search or any of the rest of the services. So, you can do things at this point like setup upgrade which would potentially upgrade the versions of modules. If you had pushed an upgrade to a module set up, upgrade happens at this point because that accesses the database. So, that needs to happen during the deploy phase. The drawback of doing too many things during the deploy phase is your site is down during the deploy phase. So, your site is not taking any requests during the deploy phase. So, really you only want to do the things here that are necessary to do because they interact with your services. Anything that doesn’t require database access or any other of the other services should be done in the build phase because the deploy phase is when your site is not taking requests. So, what Magento cloud does is it holds requests. It actually queues them. It won’t look to the user. The customer won’t see a maintenance page.

Instead, they will just have a very long wait time while the deploy phase of your deployment happens.

So, you’re holding requests, you’re mounting the writeable portions of the file system to that group of files that you generated during the build phase, you’re mounting a writeable file because most of the files are read only, but on top of those read only directories where you do need them to be writeable, you’re mounting a writeable file system on var, app/etc, pub/media and pub/static.

Then you’re opening up connections to your services. This is where the kind of the relationships part of the app.yaml file comes into play.

So, for instance, this is when you need to be concerned about things like connection information to your services. What are the host names and the port names and other service configuration.

And then you’re going to run the deploy hook.

ECE Tools deploy and this contains a lot of your kind of Magento specific deployment activities like running bin/Magento setup upgrade and many others.

Then at the end of that deploy phase you will serve the requests that have been held throughout the deploy phase.

The last phase is the post-deploy phase.

Not much goes on in the post-deploy phase. It’s a good place just to put your customization. So, during the post-deploy phase you basically have a running site with the code that you’ve just recently deployed all in place and the site is fully functioning. So, you could do things at this point like automated testing. You could do a time to first byte test. You could do cache warming, just any activity that you would want to do on a fully functioning working site. Immediately after a deployment it’s appropriate to do those things here. -