Automation

Handing key repetitive tasks to automation reduces errors and commissions, improves quality, and saves money.

Development

We support several development paradigms that all include the following automation:

  1. Highly standardized project configurations that are versioned in Git, thereby allowing:
    1. Detailed histories of all changes to project code
    2. Concurrent development of multiple features or sub-projects
    3. Multiple developers with immediate access to the latest project state
    4. Very low ramp-up time for new contributors joining the project
    5. Configurable security that allows developers from multiple participating organizations to work together while maintaining proper access limitations
  2. Every project has, at a minimum, Development environments (for as many developers as may be required), a Staging environment, and a Production environment
  3. Additional environment types are available, including Super Stagers (Staging instances with all the same resources as Production), RemDevs (remote development servers), and QA (quality assurance and training environments)
  4. Unlimited scheduled and ad-hoc deployments to any included environment
  5. Content syncs across environments to keep all design, development, and publishing processes up to date with Production

Publishing

WordPress provides some publishing automation right out of the box, as is the case with scheduled posts. We add to this capability with:

  1. Configurable publishing workflows that support formal approval processes
  2. Artificial Intelligence (AI) for default/fallback or starter content
  3. Smart Starter templates for commonly used key documents like Privacy Policy, Terms of Use, Accessibility Policy, and more

Maintenance

The native WordPress system for automated updates can be risky, especially in complex projects, because unexpected collisions can break certain features and even take down a site. We choose instead to avoid the native system and use a more elegant process of "Tested Updates and Upgrades" (because "Untested Upgrades are Downgrades!"):

  1. All new code, including updates to our own feature code as well as plugin and system upgrades, are tested first in Development environments
  2. After updates in Dev are completed, all new code is released to Staging
  3. If your process also includes QA servers, RemDev servers, or Super Stagers, we'll release to those environments as well (unless you don't want us to)
  4. Your staff are invited to join us in the testing, and we even provide test cases and prescriptive guidance where needed
  5. After you have finished testing in Staging (etc), and our tests are also done, we release to Production (and everyone is invited to test again)

Start typing and press enter to search

Scroll to Top