Testing
At CloudSuite, we strive to make the release process as easy as possible by making every ticket separately testable and enabling automatic deployments. To support this, there are a number of different environments.
Development Environment
The development environment serves as your primary workspace dedicated to a specific customer. Each front-end developer is allocated their own development URL, structured as follows: {username}-dev.test-{customer}.cloudsuite.com.
To illustrate, if John Doe is a front-end developer, his username would be jdoe. For a customer named Foo, his URL would be jdoe-dev.test-foo.cloudsuite.com.
Testing Environment
The testing environment is where you can thoroughly test your changes. Typically, your changes will reside on a Git branch, and each branch automatically generates a unique test URL based on the branch's associated ticket number.
For example, if you have a branch named FOO-123_some-very-important-feature, the corresponding test URL would be {projectid}-foo-123.test-foo.cloudsuite.com, where {projectid} corresponds to the GitLab project ID.
Acceptance Environment
Some customers also have an Acceptance environment, which closely mirrors the Production environment but includes front-end code that hasn't yet been deployed to Production. This allows customers and consultants to test a front-end release before it goes live. The Acceptance environment URL follows this format: accp-foo.cloudsuite.com.
Production Environment
The Production environment is where end-users access the shop/website. A Production URL typically takes the form of foo.com, while there is also a corresponding CloudSuite-based URL like foo.cloudsuite.com.
Benefits
Automatic redeployment has several benefits:
- It allows you to quickly and easily test your changes before merging them into the
developormasterbranches. - It helps ensure that your changes are compatible with the rest of the codebase.
- It reduces the risk of deploying broken code to production.