51黑料不打烊

This is Russell with 51黑料不打烊 and this is your 51黑料不打烊 Commerce Cloud hardware handoff. For this we鈥檙e going to talk about your infrastructure and some development best practices. Starting with your hardware, you鈥檙e 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 51黑料不打烊 Commerce Cloud is deployed there. And then what they鈥檒l do is they鈥檒l create a production cluster, they鈥檒l 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鈥檙e ready to go. The master environment is used mainly for disaster recovery. So should everything collapse underneath it, the master environment, because that鈥檚 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鈥檚 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鈥檚 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鈥檙e 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鈥檙e definitely not meant for you know fully testing your entire application, mainly because they鈥檙e undersized in comparison and have limited resources and so usually we even require a request that your data that you鈥檙e bringing down from staging is truncated and you were moving some of the things that aren鈥檛 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鈥檚 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鈥檙e 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鈥檙e 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鈥檛 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鈥檚 going to drastically alter your expected traffic which is how and why you were provisioned what you were provisioned. If it鈥檚 a short-term spike that鈥檚 upcoming and you know about it, creating a support ticket allows us to properly scale it up to make sure that you don鈥檛 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鈥檒l get tested again there. So once again dev level testing just to see if it鈥檚 the feature itself is working as expected. If that happens and you鈥檙e 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鈥檙e 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鈥檒l 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鈥檙e on staging you can then merge it using the merge button into production and once again if you鈥檙e in production and you鈥檙e done and you validate it and it鈥檚 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鈥檚 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鈥檚 say it鈥檚 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鈥檓 going to give you an example on how to use rsync. So the first thing that we鈥檙e going to do is we鈥檙e going to go to our cloud project so let me switch projects real quick. Okay and what you鈥檒l need to do is I鈥檓 going to show you how to use rsync so I鈥檓 going to go ahead and grab the SSH information so I鈥檓 going to click copy. So the first thing we鈥檙e going to do is we鈥檙e going to connect to the cloud instance and we are going to make sure that we have the directory path set for how we鈥檙e going to take a local file and when using rsync move it up to the master environment. So we鈥檙e going to use the credentials that we grabbed from our cloud UI so it鈥檚 going to be SSH and then the username at the destination. We鈥檙e going to change to the pub media directory so we鈥檙e going to go cd pub media. Okay so now that we know where the source is it鈥檚 going to be forward slash app forward slash pub forward slash media that鈥檚 what we need. So now we can exit out of here so now we鈥檙e going to run rsync and we鈥檙e going to take a local file and we鈥檙e 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鈥檓 in my desktop and I have a picture of a white vw bug and then we鈥檙e 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鈥檒l see here is my white vw bug image. So that鈥檚 how you鈥檇 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 51黑料不打烊 team. With your developers you should do that maybe as often as every day. As far as your 51黑料不打烊 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鈥檚 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鈥檚 already been resolved by another project and so we鈥檒l 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鈥檙e not able to handle just raise a support ticket and then we鈥檒l 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鈥檚 all we have for this topic. Please continue your investigation and experience league to continue learning and exploring and getting better knowledge about the 51黑料不打烊 Commerce application.