Technical onboarding - Deployments, testing, monitoring, and security

Transcript

This is Russell with Adobe and this is your Adobe Commerce hardware handoff. We’re 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 Adobe 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’re just gonna go over it quickly and at a very high level so that we have an understanding of the entire process and you’ll 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’ll 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’ve 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’t 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’re pre go live. The reason is if you’re 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’re going to be using when you’re 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’re 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’re 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’re 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’re going to be at this way you don’t actually need your actual catalog in your customers this tool will actually generate them for you you don’t have to use it you’re a if you’re especially if your catalog and your customers need some sort of customization or they’re somewhat unique then you can use any tool at your disposal such as siege or you can run Jmeter by yourself you don’t 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 Adobe Analytics or you can use Google PageSpeed to look at how your overall pages are loading so it’s getting all these are available you don’t 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’s new code that’s being introduced another tool that have that Adobe provides is the site-wide analysis tool it’s 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’ll 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 Adobe 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’ll want to use New Relic for its APM this way you can look at your transactions you can see how well they’re performing especially if you’re 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’s time to request larger hard drive capacity as far as logs the benefit for this is that all of your logs from your every Adobe Commerce instance that you have as well as Fastly all get aggregated through New Relic so you can run your queries knowing that you’re 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’re 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’ll 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’re aggregated you could just do it in one spot New Relic does also provide alerts and the hosting team at Adobe Commerce does have some managed alerts they’re very specific to what we’re looking for things like storage CPU memory and aptX as well as MariaDB and Redis memory we’re 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’re 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’s called observation for Adobe 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’ll have the same tools that our support team will be using if you’re 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 Adobe and Adobe 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’t need any pre-approval and it’s up to you to decide if you’re 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 Adobe Commerce support team once again there is a security scan tool that Adobe 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’t 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’s all we have for this topic today please continue your and your knowledge in the Adobe Commerce application at experience league and have a great day