Hi all! I have a handful of questions that revolve around getting set up for a major rewrite of a site built on top of a DatoCMS project:
- First, some context: The current DatoCMS project appears to be on a plan that doesn’t support setting up multiple environments. When I pull up the list of environments, only the primary one is listed, but attempting to fork that environment results in an error: “You’ve reached the maximum number of environments your plan allows[…]”
- My first thought was that I’d want to set up an environment to update models based on what we’ll need for the new site. But a few factors make me think it might be a better idea to just duplicate the project and edit it from there (e.g. the error I mentioned above, the scale of the changes is likely to be pretty large, there’s a mobile app that may need to continue relying on the existing project for a time). Does anyone have any thoughts to share on the pros/cons of going with an environment vs duplicating a project for this scenario?
- Assuming I duplicate the project, are there any gotchas I need to consider? Off the top of my head, I’m thinking stuff like this:
- I want to make sure the duplicated project doesn’t trigger a deployment for the old project. I’m unclear if things like build triggers are duplicated along with a project.
- Are there any costs associated with creating a duplicate of a project? I’m a bit new to Dato, and am unsure if plans support multiple projects or if the cost is per-project.
Hi @sdunham, and welcome!
I don’t know that there is necessarily a “correct” answer for these questions, because it very much depends on your intended use cases. That said, I’d be glad to offer some thoughts
- For your plan, you’re probably on an older grandfathered plan. If you wish to change it, you can write to us at firstname.lastname@example.org with your account details and we can find a similar current plan for you, with environments.
- As for environments vs projects, I think it mostly depends on what you are going to do with your current website during the migration, and how you want to deploy the new one once it’s ready.
- I think the main benefit of an environment is that you can promote sandbox environments back to primary later on. This is primarily useful when you’re making dangerous but smaller changes, like if your scope of change is limited enough that you can easily switch your frontends over to the newly-promoted sandbox afterward.
- But if you’re doing a major rewrite of everything anyway, that’s probably not a particularly suitable use case. (i.e. promoting a drastically different sandbox to primary would probably break your apps anyway)
- So if everything you’re doing is different (new schema, new frontends) a cloned project would indeed be safer, just by being completely detached from your real sites and using totally different API keys, for example. You can do anything you want in the new project without affecting the current production sites, and you can still use environments in the new one (if need be) for other reasons, like different development releases.
- There is a small cost for additional projects (currently 29€/mo under the Professional plan), whereas 8 sandbox environments are included with that plan. If you email in, we can take a look at your current grandfathered plan. But IMO that small cost per project would probably be worth it just for peace of mind
- Build triggers do not get duplicated with a project:
- The current Professional plan includes 1 project, and additional ones are 29€/mo. But if you’re on a grandfathered plan, please email us (email@example.com) and we can look into it
Hope that helps! Rewrites are always daunting but exciting.
Thanks Roger! This is super helpful. I was already leaning towards cloning, and I think this seals it.