Difference between revisions of "live site access"
Jump to navigation
Jump to search
m |
|||
| (14 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
| − | = | + | =Site Access Guidelines= |
| − | |||
| − | ==Are you giving us details for a live site of a dev/staging site?== | + | |
| + | ==Why Are We Asking For Access? Feature-Testing and Issue-Checking== | ||
| + | |||
| + | The two main reasons we will ask for access to your installation are: | ||
| + | * To install a requested feature, and test that it does what you want | ||
| + | * To investigate a reported issue | ||
| + | |||
| + | We're always happy to fix bugs and co-fund developing new features (inside a current support period) - don't worry, you can never reach our maximum 'number of questions asked' limit! | ||
| + | But, for us to check a potential bug, or add a feature that you've requested, we'll usually need access to one of your servers, so that we can see how the code interacts with your unique setup. | ||
| + | |||
| + | |||
| + | ===Are you giving us details for a live site of a dev/staging site?=== | ||
We '''highly recommend''' giving us access to your staging or dev server and not your live site. | We '''highly recommend''' giving us access to your staging or dev server and not your live site. | ||
{{idea|If you don't have one, it can be surprisingly easy to make a dev site, with the same code but a different database}} | {{idea|If you don't have one, it can be surprisingly easy to make a dev site, with the same code but a different database}} | ||
| − | ==="Why? Are you going to break | + | |
| + | ===="Why don't you want to check it on my live site? Are you going to break it?!"==== | ||
Probably not, but this is an inherent problem with complex code ''no matter what the platform'', in that we are adding new code into a complicated (and likely unique) mix of files and settings. | Probably not, but this is an inherent problem with complex code ''no matter what the platform'', in that we are adding new code into a complicated (and likely unique) mix of files and settings. | ||
| − | If you insist that we check your issue or | + | |
| + | ==Guidelines to Granting Developer Access== | ||
| + | Even if you're not giving us access to your live site, it's worth following these guidelines: | ||
| + | |||
| + | |||
| + | ===Backup First=== | ||
| + | |||
| + | * Backup the database. | ||
| + | * Backup the files (specifically the /app folder, but also worth doing the entire Magento folder while you're at it). | ||
| + | * An easy way to revert changes is to duplicate the app folder, next to the current app folder (eg. 'app_bkp'). That way to revert to a previous state you quote often just need to switch the folder names of the backup/live site. | ||
| + | * Really, make a backup :) | ||
| + | * When you make a backup, don't make the only copy on the same server as your Magento install. I've seen situations where hacked sites have had all backups deleted. | ||
| + | |||
| + | |||
| + | ===Access Credentials=== | ||
| + | |||
| + | * Make a specific login for each specific team, both on Magento and FTP/SSH. Don't be tempted to share details between teams. | ||
| + | * Once the task is complete, delete or disable the access. | ||
| + | * If providing SSH access, don't give out root user access. | ||
| + | * If providing FTP access, limit the path root usually to the folder Magento is in, and not above. | ||
| + | * Use a firewall to limit SSH and/or admin access only to specific IP addresses. | ||
| + | * When providing Magento access details, it sometimes makes sense to limit access to relevant areas. | ||
| + | * If you do limit Magento access, don't include the ability to edit User Role in the granted privileges (otherwise the user can grant themselves access to everything). | ||
| + | * In general our team will need access to a few specific areas - an easy way to deal with this is to make a User Role (System>Permissions>Roles) that you can assign dev team access to. | ||
| + | * We specifically usually need access to: | ||
| + | **Orders Page & Order Detail Page | ||
| + | **Catalog Page & Product Detail Page | ||
| + | **{{menu3|System|Tools|Compilation}} | ||
| + | **{{menu|System|Cache}} | ||
| + | **{{menu|System|Index}} | ||
| + | **{{menu|System|Configuration -> All Moogento Sections}} | ||
| + | **{{menu3|System|Tools|Configuration -> All relevant 3rd Party Extension sections}} | ||
| + | **{{menu|System|Scheduler}} (if you haven't installed AOE Scheduler, it's a good idea to keep track of cron status) | ||
| + | **(Sometimes) {{menu|Catalog|Attributes}} | ||
| + | |||
| + | |||
| + | ==Potential Issues== | ||
| + | As part of our install/test process, the extension may stop working, or throw strange outputs, until we have completed all steps. | ||
| + | |||
| + | If you insist that we check your issue (or test new features) on a live site, you agree that, while we are investigating your issue and/or installing code changes, and/or testing functionality : | ||
* The site (frontend and backend) may be unreachable | * The site (frontend and backend) may be unreachable | ||
| Line 24: | Line 74: | ||
• Usually any site downtime would be short-lived, as we perform a series of tests on every site that we work on, before passing it back - but this may extend up to an hour in some cases. | • Usually any site downtime would be short-lived, as we perform a series of tests on every site that we work on, before passing it back - but this may extend up to an hour in some cases. | ||
| − | This will be | + | This will be the same process for any development team working on a live site. |
==Our usual install/test process== | ==Our usual install/test process== | ||
# Check connection details are correct. | # Check connection details are correct. | ||
#: ''If they are not then we will put the issue on hold and email back'' | #: ''If they are not then we will put the issue on hold and email back'' | ||
| − | # Make some screenshots of the Orders Grid, and if you have pickPack installed, make some sample outputs. | + | # Make some screenshots of the Orders/Catalog Grid, and if you have pickPack installed, make some sample outputs. |
#: | #: | ||
| − | # | + | # If we're checking a bug report : |
## Confirm the issue. | ## Confirm the issue. | ||
## Try to replicate at our end. | ## Try to replicate at our end. | ||
## Develop a fix. | ## Develop a fix. | ||
#: | #: | ||
| − | #: We then upload the new code to your site : | + | #:We then upload the new code to your site : |
| − | # Disable the extension on your server. | + | # Disable the extension on your server, and enable maintenance mode. |
| + | #:''We'll try to not do this at critical times of your day but this won't always be possible - your site will be down at this point'' | ||
# Upload the changed files to your server. | # Upload the changed files to your server. | ||
# Enable the extension. | # Enable the extension. | ||
| + | # Run update/compile. | ||
# Enable error logging if not already enabled. | # Enable error logging if not already enabled. | ||
# Run tests to verify the issue is fixed. | # Run tests to verify the issue is fixed. | ||
| − | # Run tests to verify your store checkout still works : we make a test frontend order and a test backend order. | + | # Run tests to verify your store checkout still works : we usually make a test frontend order and a test backend order. |
| − | #: '' | + | #: ''Please let us know if you don't want us to make test orders'' |
# Check error logs for issues. | # Check error logs for issues. | ||
#: | #: | ||
| − | # | + | # If there are issues, or the fix/feature doesn't work, we will : |
## Roll back to the previous version | ## Roll back to the previous version | ||
| − | ## Run tests to verify your store checkout still works : we make a test frontend order and a test backend order. | + | ## Run tests to verify your store checkout still works : we usually make a test frontend order and a test backend order. |
| + | ##:''Let us know if you don't want us to make test orders please'' | ||
## Check error logs for issues. | ## Check error logs for issues. | ||
| − | == | + | ==You might see short-lived issues== |
| − | + | ||
| − | ( | + | If you see strange output, try not to panic! Same goes if you see any issues with your site (please see the list of what could happen at the top of the page). |
| − | + | It's important to not cut our FTP and/or Magento access at that point - we'll be unable to complete our tests and your site will be stuck in a half-tested state. | |
We will never normally leave a site without having done these tests so try to be patient if you see some issues. | We will never normally leave a site without having done these tests so try to be patient if you see some issues. | ||
| − | + | Feel free to send us an email if you see something strange, it may help our work, but please be aware that we may be in a different timezone to you. | |
| − | + | Quite often the support crew may be on a different timezone to the team of developers and bug squashers - ie. your email may not always be read at the same time. | |
| + | |||
| + | ==Success!== | ||
If everything goes to plan then your issue will have been fixed, and your site flying along :) | If everything goes to plan then your issue will have been fixed, and your site flying along :) | ||
| + | |||
| + | We will get in touch and ask you to run your own tests, but we will have checked that the core functionality is working. | ||
Latest revision as of 06:48, 24 June 2021
Contents
Site Access Guidelines
Why Are We Asking For Access? Feature-Testing and Issue-Checking
The two main reasons we will ask for access to your installation are:
- To install a requested feature, and test that it does what you want
- To investigate a reported issue
We're always happy to fix bugs and co-fund developing new features (inside a current support period) - don't worry, you can never reach our maximum 'number of questions asked' limit! But, for us to check a potential bug, or add a feature that you've requested, we'll usually need access to one of your servers, so that we can see how the code interacts with your unique setup.
Are you giving us details for a live site of a dev/staging site?
We highly recommend giving us access to your staging or dev server and not your live site.
If you don't have one, it can be surprisingly easy to make a dev site, with the same code but a different database
"Why don't you want to check it on my live site? Are you going to break it?!"
Probably not, but this is an inherent problem with complex code no matter what the platform, in that we are adding new code into a complicated (and likely unique) mix of files and settings.
Guidelines to Granting Developer Access
Even if you're not giving us access to your live site, it's worth following these guidelines:
Backup First
- Backup the database.
- Backup the files (specifically the /app folder, but also worth doing the entire Magento folder while you're at it).
- An easy way to revert changes is to duplicate the app folder, next to the current app folder (eg. 'app_bkp'). That way to revert to a previous state you quote often just need to switch the folder names of the backup/live site.
- Really, make a backup :)
- When you make a backup, don't make the only copy on the same server as your Magento install. I've seen situations where hacked sites have had all backups deleted.
Access Credentials
- Make a specific login for each specific team, both on Magento and FTP/SSH. Don't be tempted to share details between teams.
- Once the task is complete, delete or disable the access.
- If providing SSH access, don't give out root user access.
- If providing FTP access, limit the path root usually to the folder Magento is in, and not above.
- Use a firewall to limit SSH and/or admin access only to specific IP addresses.
- When providing Magento access details, it sometimes makes sense to limit access to relevant areas.
- If you do limit Magento access, don't include the ability to edit User Role in the granted privileges (otherwise the user can grant themselves access to everything).
- In general our team will need access to a few specific areas - an easy way to deal with this is to make a User Role (System>Permissions>Roles) that you can assign dev team access to.
- We specifically usually need access to:
- Orders Page & Order Detail Page
- Catalog Page & Product Detail Page
- SystemToolsCompilation
- SystemCache
- SystemIndex
- SystemConfiguration -> All Moogento Sections
- SystemToolsConfiguration -> All relevant 3rd Party Extension sections
- SystemScheduler (if you haven't installed AOE Scheduler, it's a good idea to keep track of cron status)
- (Sometimes) CatalogAttributes
Potential Issues
As part of our install/test process, the extension may stop working, or throw strange outputs, until we have completed all steps.
If you insist that we check your issue (or test new features) on a live site, you agree that, while we are investigating your issue and/or installing code changes, and/or testing functionality :
- The site (frontend and backend) may be unreachable
- Customers may not be able to complete an order
- Live connections to external sites may stop working
- Scheduled emails may not be sent
- Some features of the site may stop functioning
Ie: We'd much prefer to check issues on your dev/staging server than the live server.
We don't mind working on your live server, as long as you're aware of the risks.
• Usually any site downtime would be short-lived, as we perform a series of tests on every site that we work on, before passing it back - but this may extend up to an hour in some cases.
This will be the same process for any development team working on a live site.
Our usual install/test process
- Check connection details are correct.
- If they are not then we will put the issue on hold and email back
- Make some screenshots of the Orders/Catalog Grid, and if you have pickPack installed, make some sample outputs.
- If we're checking a bug report :
- Confirm the issue.
- Try to replicate at our end.
- Develop a fix.
- We then upload the new code to your site :
- Disable the extension on your server, and enable maintenance mode.
- We'll try to not do this at critical times of your day but this won't always be possible - your site will be down at this point
- Upload the changed files to your server.
- Enable the extension.
- Run update/compile.
- Enable error logging if not already enabled.
- Run tests to verify the issue is fixed.
- Run tests to verify your store checkout still works : we usually make a test frontend order and a test backend order.
- Please let us know if you don't want us to make test orders
- Check error logs for issues.
- If there are issues, or the fix/feature doesn't work, we will :
- Roll back to the previous version
- Run tests to verify your store checkout still works : we usually make a test frontend order and a test backend order.
- Let us know if you don't want us to make test orders please
- Check error logs for issues.
You might see short-lived issues
If you see strange output, try not to panic! Same goes if you see any issues with your site (please see the list of what could happen at the top of the page).
It's important to not cut our FTP and/or Magento access at that point - we'll be unable to complete our tests and your site will be stuck in a half-tested state.
We will never normally leave a site without having done these tests so try to be patient if you see some issues.
Feel free to send us an email if you see something strange, it may help our work, but please be aware that we may be in a different timezone to you. Quite often the support crew may be on a different timezone to the team of developers and bug squashers - ie. your email may not always be read at the same time.
Success!
If everything goes to plan then your issue will have been fixed, and your site flying along :)
We will get in touch and ask you to run your own tests, but we will have checked that the core functionality is working.
