We currently operate within a three-environment architecture consisting of development, staging, and production. Our marketing team has raised questions regarding whether all three environments are necessary for managing content changes such as copy updates, imagery, and other static content modifications.
Specifically, their preferred workflow is to author and manage content within the staging environment and promote those changes directly to production. Our IT team has reviewed this approach and confirmed that it aligns with the general guidance outlined in your push publishing best practices documentation: Best Practices and Troubleshooting | dotCMS Dev Site .
Given this alignment, we are seeking additional technical perspective on the viability of a hybrid workflow model. In this model:
The marketing team would create and manage content in staging and publish directly to production
The IT team would continue to develop and validate changes in the development environment, promoting them through staging and into production via the standard pipeline
We would appreciate your insights into the potential advantages, trade-offs, and risks associated with this approach, particularly in terms of environment integrity, governance, deployment consistency, and any operational considerations that may impact scalability or long-term maintainability.
In order to give you any reasonable commentary, I need to know a couple of things.
What is the purpose of your dotCMS site? Is it merely an informational/marketing site or is it providing some sort of service? That is, do you have site visitors (who might buy something) or customers (who rely on uptime)? Or some other combination.
How many pages and editors are we talking? If you have more than 10 editors, or 100, it would change my thinking.
I ran a site for a University which had over 10 other sites associated (running on the same host), with over 100 weekly editors (with publishing permission) for over 10 years using something like this model. Perhaps a piece here or there would break, or be inaccurate, but never had any downtime over a minute. If some information was wrong, they knew who to blame and it wasn’t me; and the fact that they could do their jobs quickly and easily made everyone reasonably happy. Making them jump through one more hoop wasn’t going to improve the quality of the work or their morale. If properly configured things couldn’t be broken by the editor. I didn’t allow them to make changes to the homepage directly. That had an extra stage. (Actually what I set up was multiple potential homepages, so we could see and review and swap; they could prep a holiday page or graduation page for weeks, and then later go back the next year and work from the previous one).
One thing I cannot stress enough is to make the images use a binary field and be on the content itself (blog title, blog author, blog image). Don’t use ‘file’ systems for your images or link them (on content). This way, if the content entry is purged, the image goes away, but that there’s no way to change/lose the image- user 2 can’t just see an image in a folder and change it that breaks content that user 1 set up and you aren’t left with whole folders of possibly orphaned pictures that you can’t touch for sake of history.
Content is content. It may need to be reviewed by a workflow, but it won’t ever really break the site. Code needs an extra layer. Plus, to be honest, many content issues will not really be noticed, despite review, until they are live and have more eyes.
To provide some context, our website serves as a hybrid platform. It functions as a marketing site, delivering product and market related content such as case studies and product briefs, while also supporting customer facing capabilities through the Portal. The Portal enables customers to access historical data, including orders and invoices. In addition, we offer B2B eCommerce functionality that allows a subset of approved customers to purchase products directly through the site.
From a governance and operational standpoint, we maintain a relatively small group of contributors, with fewer than 15 editors responsible for content updates and publishing that content. For code changes and publishing, we have about 6 users have the ability to deploy more advanced or code related changes.
Thank you for sharing your experience. It sounds like your model has been effective, particularly when supported by clearly defined roles, permissions, and system-level safeguards to prevent unintended changes to critical content areas.