...
- Integration environment: Developers work on their interfaces, and merge into this environment.
- Staging environment: Developers and Content Managers work together on this to test and verify the development.
- Authoring environment: Stable environment which is only used by Content and Site Managers to upload and edit contents.
- Production environment: Once the content has been approved on Authoring environment, it is pushed to Production environment.
Current dotCMS Structure
- Developers work directly on CMS. It has a lot of impacts on speed and performance in term of development.
- Content Contributors work on the same CMS Environment on which developers are working on. There work might be affected by unfinished development work.
- Code are compiled to static files and pushed directly to Temporary Folder on AWS. There is no source control to store code and data for recovery and tracking.
- A Jenkins Environment is used to deploy static files in AWS Temporary folder to both Test and Live Environments.
- There is no workflow applied for both Developers and Content Contributors.
New dotCMS Structure
- Developers work freely on their local environment and changes will get affected on Sandbox Environment when they are saved.
- All development works are kept in GIT Repository so that every changes are tracked. If there is any issue with the code, we can trace down easily and revert the code. This is also stored for backup and recovery.
- When development has been completed on Sandbox, QC can push publish to AWS Test Environment to verify.
- Once QC confirms the Test Environment is working as expected, they can be push to Authoring Environment.
- Authoring Environment belongs to CM team, only live content are input and verified here. We need to apply a content contribution workflow on this environment to ensure data is verified.
- Once the content is approved, it can be published to Live Environment.