Overview
Throughout the lifecycle of deploying, customizing, running, and version updating your CIMcloud application, you will need to be familiar with several different “environments” that instances or “copies” of your CIMcloud application (including the software code, data, and content files/images) run in. These terms are defined and diagramed in this article to help you better understand what to expect.
Four Types of “Copies”
In short, you will interact with four (4) different types of “copies” of your CIMcloud application.
- There is a “Live” copy which is what your Workers and Customers will use on a day-to-day basis.
- There are also three types of partially-live and non-live copies that are helpful when making and testing changes (so you don’t mess up your “Live” copy while preparing the changes).
The four types of “copies” are Live, Preview, Test, and Sandbox.
What Varies (by Copy)?
The four types of copies vary by:
- The software code environment they live in (Production, Staging)
- The database/data they use (Live, Sandbox)
- Whether or not they sync with your ERP system (Live database syncs, Sandbox database does not)
- The content files/images CDN they use (Live)
Diagram of “Copies” by Environment
This diagram is an overview of the four (4) types of CIMcloud “copies” (Live, Preview, Test, Sandbox) that you may interact with, along with which software code environment (Production, Staging), database (Live, Sandbox), and content files/images CDN (Live) they use.
Side-by-Side Comparison of Four Types of CIMcloud “Copies”
The following is a side-by-side comparison / quick reference chart showing the four (4) types of CIMcloud “copies” (Live, Preview, Test, and Sandbox) that you may interact with over time.
click image to enlargeA Breakdown of The Major Parts
Each copy of CIMcloud that you use / interact can be broken down into these major parts.
Software Code: Environments
There are two primary (and a 3rd developer-only) software code environments:
- Production – this is the live environment that your customers and workers use every day.
- Staging – this is a non-live code environment that houses the Preview, Test, and Sandbox copies of your CIMcloud solution.
- Local (developers only) – this environment was intentionally not shown and discussed in the diagrams or charts above, but it is part of the standard CIMcloud and CIM Pro Services developers’ workflow. It allows a local-to-the-developers-computer copy of CIMcloud to run while connected to a Live or Sandbox database. This allows a developer to efficiently edit code on the fly and have it only impact their local machine. Ultimately, they will check-in or “commit” this code to the CIMcloud Core or your Client / Local repository to see it in a Test or Sandbox copy.
Software Code: Repositories
The Code Repositories Overview article provides an overview of the two bodies of code (or “repositories”) that make your CIMcloud application work. This includes 1) the CIMcloud Core Code, and 2) you unique Client / Local Code.
Software Code: Version Updates
Version updates on software code follow this general process / flow.
Note: The Live software code can be copied from Preview (via a publish) because it is static and does not change (until the publish process overwrites it).
Database / Data: Types
The following is a summary of the two types of databases and when / why they are used.
- Live – this is your official system of record data that drives the Live copy of your CIMcloud solution. It is also used to drive your Preview copy and any Test copies you may be using.
- Sandbox – this is a throw-away “save as” copy of your entire database and data. You can use it and modify it freely, without impacting your Live database. Sandbox databases are temporary and will be discarded when the project it was created for is completed. They are two general reasons that Sandboxes are created:
- Project Sandbox (Upon Request, Additional Pricing Required) – You can create a project sandbox to help reduce the risk associated with large customization or data/content reengineering projects (i.e. if you are refactoring the category / organization structure of your entire product catalog). Project Sandboxes are available upon request for additional pricing.
- Version Update Sandbox (by CIMcloud for Major Version Updates) – Version Sandboxes are used to help you prepare for updating to the next Major CIMcloud release. These Sandboxes can help you prepare any new content or data needed + make sure your customizations are compatible (or work with CIM Pro Services or your partner to make them compatible). Check our the Version Update Process article for more details on version updates and the use of Sandboxes.
Database / Data: Moving Changes to Live
Data Changes to Live: For Version Updates (Diagram)
This diagram shows the data flow associated with a Version Update that is significant / risky enough to merit a Version Update Sandbox. This may occur when updating to a new major release of CIMcloud.
Data Changes to Live: For Projects (Diagram)
This diagram shows the data flow associated with a Project that is significant / risky enough to merit a Project Sandbox. This may occur when making large customization changes or overhauling your settings or content (i.e. a major product catalog categories overhaul) in a way that would be risky to refine and test on live data.
Data Changes to Live: Details
Data isn’t just “published” to the live database. Unlike software code, the data in databases is constantly changing (as your workers and customers use it), so overwriting the Live database’s data from a Sandbox involves significant risk and can create lots of problems. For this reason, we do not just “publish” database/data changes from a sandbox database to the live database (the live database has likely changed significantly since the sandbox was created). Changes to data in the Live database are made as follows:
- Application (CIMcloud) Data – this is the low-level data that is required to make the CIMcloud application run. It is versioned & released with our software code versions, and it is updated on your Live database during through the Version Update Process. If the version update is large enough, we will create a Version Update Sandbox so you can “test” the application data changes and fix any data compatibility issues with your customizations before the data changes are applied to your Live database.
- Customization Data – If you have customizations, they may be partially driven by data in the database. If customizations are added or changed, data changes may need to go with them. You will need to work out a strategy with your customization partner (i.e. CIM Pro Services Group) on when and how data changes are made to the Live database. Some changes can be made without causing issues with your Live application, enabling you to do the work directly in the Live database. Other changes may negatively impact the Live application, requiring you to use a Project Sandbox to complete and test the work, and then scheduling a temporary “under maintenance” outage to actually publish the code changes and update the Live data.
- Settings, Product, and Content Data – There are strategies that can be used to make changes to this type of data in your Live database, while keeping it “hidden” from your users as refine and test the data, enabling you to make the changes without negatively impacting your users. Sometimes you will need to change critical settings data that is application-wide and can not be made without impacting users. For these cases, you may want to consider a Project Sandbox (additional pricing applies) to “test” the changes before making them on the live system.
ERP Sync
The following options exist for the ERP Sync between your ERP accounting system and the CIMcloud platform database.
- Live (ERP Sync) – The ERP Sync Tool syncs data between your live ERP system and the Live CIMcloud platform database. Any CIMcloud copy that uses the Live database (including Live, Preview, and Test copies) will typically impact the ERP sync in the same way.
- Sandbox (No ERP Sync) – Sandbox copies of CIMcloud use Sandbox databases that do NOT sync with your ERP system. The ERP Sync tool only interacts with the Live database.
Content Files / Images
All copies of your CIMcloud platform use the same Live AWS (Amazon Web Services) “bucket”. This bucket stores and delivers images and files through Amazon’s CDN (Content Delivery Network). This includes all images / photos (i.e. product photos, slide show photos, web page photos, graphics, etc) and content files (like PDFs, documents, spreadsheets, etc).
Warning: Changes to images and files, from ANY copy of CIMcloud (Live, Preview, Test, or Sandbox) impact the Live bucket.
Domain Names / URLs
Each copy of your CIMcloud platform can be accessed via a website URL / domain name. All copies of your CIMcloud platform have automatically created domain names (URLs) for:
- Customer Site(s), and
- The Worker Portal
In addition, you can point your own domain name(s) to your customer sites (i.e. http://www.YOURNAME.com).
The following is a breakdown of the pattern used for automatically created and provided URLs:
- Live
- Main Customer Site: https://SITENAME.cimproduction.com
- Worker Portal: https://SITENAME.mycimcloud.com or https://SITENAME.mycimproduction.com
- Preview
- Main Customer Site: https://SITENAME.cimstaging.com
- Worker Portal: https://SITENAME.mycimstaging.com
- Test
- Main Customer Site: https://SITENAME-BRANCH.cimstaging.com
- Worker Portal: https://SITENAME-BRANCH.mycimstaging.com
- Sandbox
- Main Customer Site: https://SITENAME-sandbox.cimstaging.com
- Worker Portal: https://SITENAME-sandbox.mycimstaging.com
- Note: If you have more than 1 sandbox in use, the URL may vary (i.e. you might see something like https://SITENAME-sandbox2.mycimstaging.com)
Note: The following are variables in the above patterns that should be replaced with specific values provided to your by CIMcloud.
- SITENAME = the specific nickname provided to you by CIMcloud
- BRANCH = a specific branch nickname provided to you by CIMcloud when a test copy is created