QA testing notes and findings are thoroughly documented in each Trello ticket, so it’s clear what we looked at and if we fixed any issues. Update maintenance log with Trello ticket URL and date of launch.Post-Launch: Re-check "Top 10" pages on production.Post-Launch: Confirm that any migration scripts are running properly.These are pages that have high traffic, are important to stakeholders, have complex/custom functionality, or have broken in the past). QA Tester: Test a representative sampling of pages throughout the site (we have our clients give us a list of “Top 10” pages.QA Tester: Test all updated modules per our library of testing instructions curated by our Development team.QA Tester: Confirm that all updates have been completed as expected by comparing current module list from production against that of the test environment.Run all module and core updates in a test environment.Double-check our internal documentation to ensure that any custom code or unique aspects of the website’s architecture will not require special treatment during these updates.Re-evaluate the patches in place and verify if they are still necessary.To minimize content/database differences for the QA person, copy the production database down to the test environment.Examples include: Field Collection becoming deprecated, Acquia or Pantheon forcing a PHP upgrade, Module/Core version incompatibilities, etc. Check if there are any modules or other elements of this website which are likely to become deprecated, or are expecting major updates/changes in the near future.Check if there are any old multidev environments that are no longer necessary, and remove them.Here’s what a typical maintenance checklist looks like: Our maintenance process includes environment cleanup, checking for upcoming module deprecations, thorough QA testing, documentation of findings, and remediation of any discrepancies. If a security update does come out, you want the ability to roll it out immediately-not get stuck fixing a ton of bugs. The longer you wait to update, the more interconnected changes you need to test at once, and the more likely something will break. But more importantly, non-security updates typically have smaller changes which are less risky and easier to test. For one, modules will sometimes come out with new features/functionality that could add value to your application. Keeping modules up to date can be just as important as performing security updates. We use Butler automations in Trello to generate these recurring tickets. In addition, we perform non-security updates on a monthly (sometimes quarterly) basis. For each release, we check all our client’s websites to determine if the update is applicable given the set of modules and version of Drupal they’re using. We’ve set up automated notifications in a dedicated Slack channel so we know as soon as updates are released and can take immediate action. Security releases for contributed modules occur every Wednesday, and for Drupal core they occur once a month. It’s up to you to make sure these updates are implemented immediately. Once a security release is made public, your site’s vulnerability increases, because now anyone-including hackers-can read the details of what the security issue was, and try to attack any sites that haven’t incorporated the solution quickly enough. Once identified, a security update is released.īut these factors alone don’t make your site secure. Drupal’s security team validates and responds to security issues. These contributions are also reviewed by the community, ensuring developers adhere to Drupal’s coding standards. It’s an open source platform, which means contributions are being made by thousands of programmers in the world-wide Drupal community. Drupal is well-known for being a highly secure Content Management System (CMS).
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |