Answers.Body: <p>Craft's <a href="https://craftcms.com/docs/3.x/project-config.html" rel="nofollow noreferrer">Project config</a> is really made for updating changes from staging to production.</p>
  <p>When it comes to making changes across a fleet of (different) sites, you're somewhat on your own there. You might think of all of your sites as the same but Craft is thinking of each site independently because that's how it's designed.</p>
  <p>It sounds to me that one way to handle this might be to try to automate migrations between installs? You change one site, test it, and then move the migration to the next client site/grouping.</p>
  <p>After all, if you're changing or adding fields, for example,  you're most likely going to be changing the (GraphQL) code that also queries those fields as well or everything is going to fall down pretty quick.</p>
  <p>Something like <a href="https://plugins.craftcms.com/migrationassistant" rel="nofollow noreferrer">Migration Assistant</a> could useful here?</p>
  <p>Also, I'm not sure how your devops is setup but theoretically you could share code between installs (same templates, plugins, etc.) The vendor, migrations,  templates, and other code  directories could be symlinked in from a central spot so when they get updated, the rest of the sites get updated as well. Once the build process is complete you could fire off a <code>craft migrate/up</code> command line that propagates across each install to make sure everything updates.</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2020-10-12T20:18:32.067Z
Answers.Text: Thanks for your input, it's welcome. As far as similarity between each site goes - from a fields, sections, entry types perspective - they're all identical. The only real difference is the content, users and number/naming of sites so the GraphQL queries made by the front end can be the same across installations. Since they're otherwise tightly coupled, it's one BitBucket repo containing ReactJS front end and the Craft back end.
Answers.UserDisplayName: Wallace
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2020-10-11T19:53:53.770Z
Answers.LastActivityDate: 2020-10-11T19:53:53.770Z
Answers.UserDisplayName: RitterKnight
Body: <p>We're developing an application that uses a multi-site Craft back-end with a JS front-end, making use of GraphQL. The intention is to maintain a single codebase that can be used to deploy new and update existing instances of the application.</p>
  <p>Each client has their own installation of Craft (currently Craft 3.5), with multiple sites in each. To illustrate:</p>
  <p>Client A:</p>
  <ul>
  <li>site 1, clienta.ourdomain.com/someslug</li>
  <li>site 2, clienta.ourdomain.com/anotherslug</li>
  </ul>
  <p>Client B:</p>
  <ul>
  <li>site 1, clientb.ourdomain.com/customslug</li>
  <li>site 2, clientb.ourdomain.com/orangeslug</li>
  <li>site 3, clientb.ourdomain.com/frenchslug</li>
  </ul>
  <p>Client C:</p>
  <ul>
  <li>site 1, clientc.ourdomain.com/potatoes</li>
  </ul>
  <p>...etc</p>
  <p>The underlying Craft components (i.e. fields, sections, entry types, plugins, etc.) are identical across clients. Initially, I thought that project-config would be all over this until I realised that site data is held in Project Config. With each client having a different number of sites with different slugs etc., that rules out keeping project config in a single git repository.</p>
  <p>This, therefore, presents a maintenance and deployment nightmare. As it stands, the only (terrible) option as I see it is:</p>
  <ul>
  <li>Create some kind of baseline config and store a matching SQL dump with it</li>
  <li>Remove project config from the repo</li>
  <li>Manually create migrations for any subsequent modifications.</li>
  </ul>
  <p>I had considered forks of the main repo for each Client but again, if there's any project config in those, there's the potential to hose a client's site by modifying site-related data.</p>
  <p>The ideal solution would be the ability to configure (!) project config, such that it ignores anything to do with sites. As far as I can see from the generated yaml, sites are only referenced in defining the site itself, and sections' site settings. Configuring the latter programmatically when a site is created is fairly straightforward.</p>
  <p>If anyone has any experience of a similar setup, I'd very much appreciate the benefit of their experience.</p>
  
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2020-10-12T20:23:25.577Z
Comments.Text: Appreciate the red pen to my English @Brad, it had been a long day...
Comments.UserDisplayName: Wallace
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2020-10-12T22:37:39.467Z
Comments.Text: Just trying to satisfy my OCD. :)
Comments.UserDisplayName: Brad Bell
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2020-10-28T09:12:22.307Z
Comments.Text: I'm not ruling out using project-config for this, I'd rather not go down the road of maintaining future updates through migrations. 
  I am instead considering <editing> project-config between dev and staging deployments, but the question is whether that's done directly to the YAML config files before sync, or by using the [project-config Service](https://docs.craftcms.com/api/v3/craft-services-projectconfig.html)
Comments.UserDisplayName: Wallace
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2023-11-16T09:07:39.197Z
Comments.Text: @Wallace found your post, because I have nearly the same question. How did you eventually solve your problem? Any hints and information very appreciated. Thanks!
Comments.UserDisplayName: Henrik
Tags: <craft3><multi-site><deployment><projectconfig>
Title: Maintaining and deploying many multi-site from a single codebase
ThreadText: # Maintaining and deploying many multi-site from a single codebase
  
  (Asked by: username_0 on 2020-10-10)
  
  We're developing an application that uses a multi-site Craft back-end with a JS front-end, making use of GraphQL. The intention is to maintain a single codebase that can be used to deploy new and update existing instances of the application.
  
  Each client has their own installation of Craft (currently Craft 3.5), with multiple sites in each. To illustrate:
  
  Client A:
  
  * site 1, clienta.ourdomain.com/someslug
  * site 2, clienta.ourdomain.com/anotherslug
  
  Client B:
  
  * site 1, clientb.ourdomain.com/customslug
  * site 2, clientb.ourdomain.com/orangeslug
  * site 3, clientb.ourdomain.com/frenchslug
  
  Client C:
  
  * site 1, clientc.ourdomain.com/potatoes
  
  ...etc
  
  The underlying Craft components (i.e. fields, sections, entry types, plugins, etc.) are identical across clients. Initially, I thought that project-config would be all over this until I realised that site data is held in Project Config. With each client having a different number of sites with different slugs etc., that rules out keeping project config in a single git repository.
  
  This, therefore, presents a maintenance and deployment nightmare. As it stands, the only (terrible) option as I see it is:
  
  * Create some kind of baseline config and store a matching SQL dump with it
  * Remove project config from the repo
  * Manually create migrations for any subsequent modifications.
  
  I had considered forks of the main repo for each Client but again, if there's any project config in those, there's the potential to hose a client's site by modifying site-related data.
  
  The ideal solution would be the ability to configure (!) project config, such that it ignores anything to do with sites. As far as I can see from the generated yaml, sites are only referenced in defining the site itself, and sections' site settings. Configuring the latter programmatically when a site is created is fairly straightforward.
  
  If anyone has any experience of a similar setup, I'd very much appreciate the benefit of their experience.
  
  **Tags:** craft3, multi-site, deployment, projectconfig
  
  > **Comments:**
  > **username_0**: Appreciate the red pen to my English @username_1, it had been a long day...  
  > **username_1**: Just trying to satisfy my OCD. :)  
  > **username_0**: I'm not ruling out using project-config for this, I'd rather not go down the road of maintaining future updates through migrations.  I am instead considering <editing> project-config between dev and staging deployments, but the question is whether that's done directly to the YAML config files before sync, or by using the [project-config Service](https://docs.craftcms.com/api/v3/craft-services-projectconfig.html)  
  > **username_2**: @username_0 found your post, because I have nearly the same question. How did you eventually solve your problem? Any hints and information very appreciated. Thanks!  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_3 on 2020-10-11. Score: 1
  
  Craft's [Project config](https://craftcms.com/docs/3.x/project-config.html) is really made for updating changes from staging to production.
  
  When it comes to making changes across a fleet of (different) sites, you're somewhat on your own there. You might think of all of your sites as the same but Craft is thinking of each site independently because that's how it's designed.
  
  It sounds to me that one way to handle this might be to try to automate migrations between installs? You change one site, test it, and then move the migration to the next client site/grouping.
  
  After all, if you're changing or adding fields, for example, you're most likely going to be changing the (GraphQL) code that also queries those fields as well or everything is going to fall down pretty quick.
  
  Something like [Migration Assistant](https://plugins.craftcms.com/migrationassistant) could useful here?
  
  Also, I'm not sure how your devops is setup but theoretically you could share code between installs (same templates, plugins, etc.) The vendor, migrations, templates, and other code directories could be symlinked in from a central spot so when they get updated, the rest of the sites get updated as well. Once the build process is complete you could fire off a `craft migrate/up` command line that propagates across each install to make sure everything updates.
  
  > **Comments:**
  > **username_0**: Thanks for your input, it's welcome. As far as similarity between each site goes - from a fields, sections, entry types perspective - they're all identical. The only real difference is the content, users and number/naming of sites so the GraphQL queries made by the front end can be the same across installations. Since they're otherwise tightly coupled, it's one BitBucket repo containing ReactJS front end and the Craft back end.  
  
  ---
  
  