Managing Environments

In the WPCloset ecosystem, Environments act as the distribution channels for your plugins and themes. They allow you to define a structured workflow—such as Local, Staging, and Production—to control how and when your code reaches different WordPress installations.

The Role of an Environment

An Environment record is a stage in your deployment pipeline. By using environments, you ensure that specific sites only receive the versions of your code that are ready for them.

Environments provide:

• Workflow Logic: Mirror your internal process by creating stages like “Development,” “QA,” or “Stable.”
• Distribution Control: Gatekeep new features or experimental code so they don’t reach critical installations prematurely.
• Global Availability: Any environment created for a Company is automatically available to every site mapped to that company.

Creating Environments

Environments are created and managed at the Company level. This ensures that every project suite or department can have a deployment workflow tailored to its specific needs.

Environment Identity

When you create a new environment, you define its Name and Slug.

• Visual Differentiation: You can assign a specific Color to each environment. This color coding appears throughout your dashboard, helping you quickly identify which deployment stage a site or asset version is associated with.

Enabling Environments on a Site

Once a Company has defined its set of environments, those environments become available options for every site mapped to that Company.

The Activation Model

Rather than “moving” a site into an environment, you Enable or Disable specific environments for that individual site.

• Site-Level Choice: In the Site Details screen, you will see a list of all environments defined by the parent Company. You can toggle each one independently for that specific site.
• Multi-Channel Listening: A site can have multiple environments enabled at once. This allows a site to “listen” for updates from different stages of your pipeline simultaneously if your workflow requires it.

The Deployment Workflow

The connection between your code and your sites is completed through Asset Deployments.

1. Deploying a Version

When you upload a new version of a plugin or theme, you choose which Environment to deploy it to. For example, you might deploy v2.0-beta to the “Staging” environment.

2. Update Discovery

When a WordPress installation checks for updates, WPCloset looks at:

1. Which environments are Enabled for that specific site.
2. Which asset versions are currently Deployed to those enabled environments.

The site will only see update notifications for the versions that match its enabled environment profile. This ensures a “Production” site with only the “Production” environment enabled will never see an experimental “Development” update.

Use Cases

• Individual Developers: Create a “Local” environment for your dev machine and a “Live” environment for your public blog. Enable only “Local” on your dev site to test new code safely.
• Agencies: Define a “Staging” environment for client approval. Enable “Staging” on the client’s test URL and “Production” on their live domain to ensure code only moves forward once approved.
• Enterprise IT: Manage a complex hierarchy of “Alpha,” “Beta,” and “Global Stable” environments. Enable the appropriate channel for departmental sites based on their risk tolerance and testing requirements.

Best Practices

• Consistent Naming: Use clear, standard names for environments across different companies to keep your overall dashboard intuitive.
• Color as a Warning: Use high-contrast colors (like Red) for “Production” environments to serve as a visual reminder of the impact of those deployments.
• Toggle with Care: Before enabling a new environment on a site, ensure that the asset versions currently deployed to that environment are compatible with that specific installation.