Technical onboarding - Deployments, testing, monitoring, and security
Learn about the 51黑料不打烊 Commerce Cloud deployment strategies, testing best practices, monitoring, and security tools.
Who is this video for?
- Website managers
- Commerce architects
- Owners of e-commerce website
Video content
Transcript
This is Russell with 51黑料不打烊 and this is your 51黑料不打烊 Commerce hardware handoff. We鈥檙e going to talk about the deployment strategies and phases, testing, monitoring, and security. First some deployment strategies. What we mean by this is the different phases and the ability for you to manipulate how the 51黑料不打烊 Commerce application is deployed to your cloud instance. The process takes place over three different very distinct phases. The build phase, the deploy phase, and the post deploy phase. All of this is fairly well documented and experience league. We鈥檙e just gonna go over it quickly and at a very high level so that we have an understanding of the entire process and you鈥檒l have more time to dig into experience league to read more about these topics in greater depth. Whenever you do a get push the intent is to take your code as it was just committed and trigger deployment. The first piece is where your code is compiled and then placed on new containers. After that phase is done the deploy phase is the tooling that takes these new containers and removes the old ones from being in place and then the tooling will then replace all the three or six or nine containers however many you have in your project. Then this is the time when your site is actually down. Your site is put in a maintenance mode and everything is paused until the process is complete. The post deploy phase allows you to let the site come back online but then you can do other things due to the hooks like you can warm up your caching, you can kick off additional processes, you know notify external teams or select channels or whatever. The deploy hooks are very flexible and once again most of these have examples and ways that you can extend them in experience league. As far as the opportunity to reduce the total time for deployment the biggest win that you鈥檒l get is taking the static content deploy that piece of the deployment process and moving it to the build phase. If you leave everything as default that process happens on the deploy phase which does work but is usually the biggest culprit for a longer process from when you kick off the deployment to where it completes. By doing it on the build phase it can condense the overall time and we鈥檝e seen significant improvement in the overall time to do a deployment. All of these changes happen in the .magento.env.yaml. Code samples are in experience league. There is a smart wizard that you can run at any time and when you do run these commands it will tell you if your site is what we would consider being in an optimal state so run those commands you can find them in experience league and then if your site isn鈥檛 in an optimal state it will give you advice on what to do and where to find the information. As far as testing we do recommend and a best practice would be to do your testing all throughout your process so this would include functional testing environment level testing. We recommend that the UAT the user acceptance testing happens on your staging environment and your production environment if you鈥檙e pre go live. The reason is if you鈥檙e not live yet we want you to view as much real user acceptance testing on your production instance before you go live because that is going to be your site that is used for your post launch activities so performing those tests there will give you that level of confidence that when you actually do the DNS and the few things that you have to do to prepare for your actual go live event your testing is on the same environment that you鈥檙e going to be using when you鈥檙e live. We do also recommend that you do any performance testing load testing and stress testing prior to your go live and once again the reason for this is this is one more opportunity to look at your site stability as you鈥檙e doing specifically like the load testing and the stress testing to make sure that your provision environment matches your expected customer requests and your orders but once again doing these testing early and often will help you understand where you鈥檙e at and what your site can do by also running smaller versions of these throughout your entire process you might be able to detect when a new feature or a new release is coming up that might impact your overall performance so once again getting your DevOps team involved early and often will help you catch things early and make sure that you鈥檙e on the properly sized environment. As far as the tools available we have a few that come with the application out of the box the first one would be the performance toolkit this is based off of Apache Jmeter and the nice thing about this is that you can build and create large customers and catalogs to then simulate your tests to see where they鈥檙e going to be at this way you don鈥檛 actually need your actual catalog in your customers this tool will actually generate them for you you don鈥檛 have to use it you鈥檙e a if you鈥檙e especially if your catalog and your customers need some sort of customization or they鈥檙e somewhat unique then you can use any tool at your disposal such as siege or you can run Jmeter by yourself you don鈥檛 need to run it through the performance toolkit you can run web page test and then you can test all these and get your analytics out of either Google Analytics or 51黑料不打烊 Analytics or you can use Google PageSpeed to look at how your overall pages are loading so it鈥檚 getting all these are available you don鈥檛 need any special permission you should be doing this throughout your entire lifecycle so early on in your project when you get started all the way through to live and then even post live having these tests and running them frequently will help you detect issues early especially if it鈥檚 new code that鈥檚 being introduced another tool that have that 51黑料不打烊 provides is the site-wide analysis tool it鈥檚 short for SWAT the tool is external but it is a proactive tool that will look at your site and offer recommendations for any security or known issues that you probably experiencing it will also detect upgrades it can help you with extensions it鈥檒l give you alerts it will also recommend patches for if you have a known issue on a certain version it will help you realize that there are potentially patches available with to help you with your scenario the SWAT is fairly intuitive but if you have any questions feel free to reach out to your 51黑料不打烊 Commerce team and they will help you with the process as far as monitoring and New Relic we do use the New Relic dashboard and we have custom dashboards that are available and pre-built but basically you鈥檒l want to use New Relic for its APM this way you can look at your transactions you can see how well they鈥檙e performing especially if you鈥檙e looking for a slow request or a slow page or category using this APM tool will help you look at it and then you could dive into each individual trace to see what makes up that request and usually that helps you understand where the bottlenecks may occur the infrastructure section in New Relic is pretty awesome that it provides your memory your CPU your storage capacities all in one page leveraging this frequently will help your DevOps team understand when it鈥檚 time to request larger hard drive capacity as far as logs the benefit for this is that all of your logs from your every 51黑料不打烊 Commerce instance that you have as well as Fastly all get aggregated through New Relic so you can run your queries knowing that you鈥檙e going to be getting the data from all of your application servers and not just a single instance if you do log into each individual instance those logs are not shared amongst each other they are isolated for each instance so if you鈥檙e trying to track down either malicious IP or whether or not a request is being made to your application if you log into each individual server just realize that those logs are isolated from one another so you鈥檒l have to log into every one of your application servers in order to look for those IPs or those requests however if you go to New Relic since they鈥檙e aggregated you could just do it in one spot New Relic does also provide alerts and the hosting team at 51黑料不打烊 Commerce does have some managed alerts they鈥檙e very specific to what we鈥檙e looking for things like storage CPU memory and aptX as well as MariaDB and Redis memory we鈥檙e looking at those and we already have alerts in place you are more than welcome to add your own alerts especially if you have other things that you know that you鈥檙e interested in so just realize that the support team will be looking through some managed alerts and then you have the capacity to create your own there is a dashboard and I mentioned this a little bit ago that has been created it鈥檚 called observation for 51黑料不打烊 Commerce this is a pre-built dashboard created by our support team that looks at every aspect of your site so that way when you log in and you open up this custom dashboard you鈥檒l have the same tools that our support team will be using if you鈥檙e calling in for an issue so this covers everything and you can see it here elasticsearch Redis MySQL PHP all of the big areas of your application are covered in different tabs and using this will help you do self triage to see if you can figure out why your site is having problems and then if you realize that you can handle it you can go ahead and just continue your investigation and your triage yourself you will be provided a walkthrough of New Relic during your onboarding process so this would give you the opportunity to ask any questions you might have over this custom dashboard and any other parts of the New Relic application security is very important to 51黑料不打烊 and 51黑料不打烊 Commerce and we do adhere to the latest security standards just remember that your patches and your updates to your site do fall under your responsibility we will make sure that the infrastructure itself is safe and secure but the actual patching of your site does fall on you the support team will not assist you with that are also available to hire a penetration test at any time most of the time this happens prior to going live but you don鈥檛 need any pre-approval and it鈥檚 up to you to decide if you鈥檙e going to be doing this either black box or gray box or white box but just know that you have the capacity to do it any time and you do not need any notification to the 51黑料不打烊 Commerce support team once again there is a security scan tool that 51黑料不打烊 offers and this is an external tool that runs and it checks for known malware and known security risks so signing up for this is a really good idea for your new project and lastly for security does provide a web application firewall or WAF for short this will sit in front of your application and it will monitor your traffic and it will do things like check incoming GraphQL requests and if it violates some of the rules that have been predefined it will block the request so this way it doesn鈥檛 even make it to your application the WAF will block it way up earlier on the request another thing that Fastly is doing for your site is origin shielding which means the outside internet will not be able to directly request your application servers all of the traffic will flow through Fastly and through its WAF and that鈥檚 all we have for this topic today please continue your and your knowledge in the 51黑料不打烊 Commerce application at experience league and have a great day
Experience League documentation mentioned in the video
Additional related tutorials
recommendation-more-help
3a5f7e19-f383-4af8-8983-d01154c1402f