Technical onboarding - Infrastructure and development best practices

Transcript

This is Russell with Adobe and this is your Adobe Commerce Cloud hardware handoff. For this we’re going to talk about your infrastructure and some development best practices. Starting with your hardware, you’re going to be provisioned a couple of different environments. The first one being the master environment. This is the very first environment that is created through the tooling and automation and then the current version of Adobe Commerce Cloud is deployed there. And then what they’ll do is they’ll create a production cluster, they’ll create a staging cluster under that, and then usually one maybe two integration environments will be generated on your behalf. So that way on day one you have all of the expected environments and you’re ready to go. The master environment is used mainly for disaster recovery. So should everything collapse underneath it, the master environment, because that’s how it was used to provision the production and staging integration environments in the beginning, will be reused for that purpose. So should something catastrophic happen, that’s the intent of the master branch. Not only does it start your project, but it can be used to restore it. Your production is a dedicated, isolated infrastructure as a service cluster and once again this environment is meant for production, it’s meant for load testing, penetration testing before launch, and then obviously it will be used as your primary site when your site is live. Staging is also dedicated, it should be identical or very very close to your production environment. You can also do performance testing, penetration testing, and you can use that after you’re live to do those same functionalities, but for your pre-live you might as well just use the production environment for those more exhaustive tests like final UAT and penetration testing. The integration environments, those are meant for like developer level and basic code testing. They’re definitely not meant for you know fully testing your entire application, mainly because they’re undersized in comparison and have limited resources and so usually we even require a request that your data that you’re bringing down from staging is truncated and you were moving some of the things that aren’t completely necessary. So for example if you have like a hundred thousand customers, maybe on integration you only have like a thousand, just enough to test it to make sure that it’s going to work as expected. So how staging and production might differ from integration. So the staging and production environments, these are dedicated to your project. You are unable to branch from these. You’re also unable to install anything extra like a WordPress install. These do come with SendGrid, Fastly, and New Relic, so that way you can do full end-to-end testing of your entire application. And then also on this one backups are automated and if you need one a restoration can be done via support ticket. And then your integration environment, this is where SendGrid, Fastly, and New Relic are not available. You are in more control over your backup process and your restoration process. You can do that all through the UI. And once again these are smaller containers and they have a significantly less resources than your staging and production. So once again limit this to just simple developer level and basic code testing. As far as your production and your staging environments, these are your high availability. They’re balanced over three separate nodes. This could change depending on the size of your project. You might actually start with six or even nine or larger, but most of our sites start with three nodes. They can be scaled vertically with no downtime. These backups are scheduled and automated for you so you don’t have to worry about that. But if you do need to restore from one you do need to create a support ticket. And once again, production, the up sizing automatically happens. So once again if you have a runaway log or something that chews up a lot of space will up size for you. And then once again you can also request an up size if you know that you have an upcoming event that’s going to drastically alter your expected traffic which is how and why you were provisioned what you were provisioned. If it’s a short-term spike that’s upcoming and you know about it, creating a support ticket allows us to properly scale it up to make sure that you don’t experience any issues. So for code merging and deployment strategy, the expectation is the code will flow up and your data and your media and other assets will flow down. So a developer will create a small feature and then push it to one of your integration environments that may or may not be nested underneath your parent integration environment. If so it’ll get tested again there. So once again dev level testing just to see if it’s the feature itself is working as expected. If that happens and you’re ready you can go ahead and merge the integration environment into staging and do your first round of real QA and real UAT. If all that goes well and you’re ready for a production deployment you can simply merge it into production. Once that happens you will do your final UAT and your final QA there especially if this is pre go live. And then if everything goes good there, once again the best practice is to merge your production environment into master so that way it always is in sync with the current most stable release of production. So here is what the project will look like in your cloud UI. You’ll notice here that we have our master branch, our production branch, our staging and integration branch. So when you are doing your code deployment you will click here and then you can merge this into the staging environment by using the merge button. If you’re on staging you can then merge it using the merge button into production and once again if you’re in production and you’re done and you validate it and it’s a stable release you can then merge this into the master environment. One other thing to note is that you can have your own external repository. We do provide one with your cloud project but if you have your own Bitbucket or GitLab you are able to use it and all of that information and documentation can be found on experience.ly. As far as migrating your database and some media files if the use case is that your current release does require a let’s say it has a new image that you want to include with it. The code will go up separately and then for the media asset let’s say it’s an image or PDF or what have you your methods available to you are rsync you can use the cloud CLI or you can use sftp. So I’m going to give you an example on how to use rsync. So the first thing that we’re going to do is we’re going to go to our cloud project so let me switch projects real quick. Okay and what you’ll need to do is I’m going to show you how to use rsync so I’m going to go ahead and grab the SSH information so I’m going to click copy. So the first thing we’re going to do is we’re going to connect to the cloud instance and we are going to make sure that we have the directory path set for how we’re going to take a local file and when using rsync move it up to the master environment. So we’re going to use the credentials that we grabbed from our cloud UI so it’s going to be SSH and then the username at the destination. We’re going to change to the pub media directory so we’re going to go cd pub media. Okay so now that we know where the source is it’s going to be forward slash app forward slash pub forward slash media that’s what we need. So now we can exit out of here so now we’re going to run rsync and we’re going to take a local file and we’re going to push it up to the pub media on this master environment. So the command for this is rsync dash avrp and then the source is going to be on my I’m in my desktop and I have a picture of a white vw bug and then we’re going to do dash e and then SSH and then the user at cloud app pub media.

Perfect so now if I go back and I connect to my environment and I change into pub media you’ll see here is my white vw bug image. So that’s how you’d use rsync to move a file from your local environment up to a cloud environment. As far as implementation best practices we do want to make sure that your project is a success so we do offer a lot of articles in experience league that are specifically reserved for best practices as well as other development standards. As far as your project goes a best practice certainly would be to have a frequent and ongoing conversation with your developers that will probably happen more often than you with your Adobe team. With your developers you should do that maybe as often as every day. As far as your Adobe team every two weeks is fairly normal it just depends on the duration of your project if your project is going to go for six weeks then maybe your meeting cadence will be every week but if it’s going to go for like nine months then every two weeks is you know usually pretty pretty safe. It is recommended that you use as much out of the box functionality as you can. This is great because it helps reduce your overall technical debt and then it makes your upgrade path so much easier. Keeping the software up to date is paramount and we do offer a lot of patches for known issues or complications that people come into so we will be able to support you by either providing you a pre-built patch sometimes if there is something unique just for you we can custom build a patch for your project but most times it’s already been resolved by another project and so we’ll be able to link you to a knowledge base article and sometimes even provide a patch to solve your problem. We do request that you try to mitigate as many issues on your own as you can but then as soon as you realize that it is something that you’re not able to handle just raise a support ticket and then we’ll start the investigation process and once again either refer you to existing knowledge base articles or experience link tutorials or even provide a patch. That’s all we have for this topic. Please continue your investigation and experience league to continue learning and exploring and getting better knowledge about the Adobe Commerce application.