Answers.Body: <p>Something I wish I knew a long time ago, as it has bitten us quite a few times already in the past. Nothing as bad as having an automated deployment process that fails once in a while.</p>
  <p>I'm sharing it here, but I believe it would be good to add it to the knowledge base too (<a href="https://craftcms.com/knowledge-base/deployment-best-practices" rel="noreferrer">https://craftcms.com/knowledge-base/deployment-best-practices</a>)</p>
  <p>The solution is to split up the structural migration and the content migration.</p>
  <p>Pull the update for git and then run</p>
  <pre><code>craft update/composer-install --interactive=0
  craft migrate/all --no-content --interactive=0
  craft project-config/apply --force
  craft migrate --track=content --interactive=0
  </code></pre>
  <p>Pretty straightforward and simple, but I was not aware of the --no-content flag until recently as it not in the command help.  I hope it will help somebody in the future!</p>
  <p>(The --interactive=0 and --force flags are there because it is an unattended deploy)</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2021-01-08T14:29:17.680Z
Answers.Text: Thanks for pointing this out, Tim. Updated the Knowledge Base article to mention splitting out these steps along with your non-interactive flags.
Answers.UserDisplayName: Matt Stein
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2020-12-10T15:39:12.600Z
Answers.LastActivityDate: 2020-12-11T08:16:20.023Z
Answers.LastEditDate: 2020-12-11T08:16:20.023Z
Answers.UserDisplayName: Tim Bertens
Body: <p>In the knowledge base article there are 4 steps described to automate the deployment process</p>
  <ol>
  <li>Pull updates for git</li>
  <li>Run composer install</li>
  <li>Run migrate/all</li>
  <li>Run project-config/apply</li>
  </ol>
  <p>The problem with this is that when you have pushed a structural change (eg. adding a new field) and a content migration (adding new entry using that new field) at the same time, it fails because you cannot migrate into a non existing field of course</p>
  <p>You cannot flip step 3 and 4 as in that scenario changes made to Craft CMS are not yet available in the database.</p>
  
Tags: <craft3><migration><deployment>
Title: Automated deployment with content migrations and structural changes
ThreadText: # Automated deployment with content migrations and structural changes
  
  (Asked by: username_0 on 2020-12-10)
  
  In the knowledge base article there are 4 steps described to automate the deployment process
  
  1. Pull updates for git
  2. Run composer install
  3. Run migrate/all
  4. Run project-config/apply
  
  The problem with this is that when you have pushed a structural change (eg. adding a new field) and a content migration (adding new entry using that new field) at the same time, it fails because you cannot migrate into a non existing field of course
  
  You cannot flip step 3 and 4 as in that scenario changes made to Craft CMS are not yet available in the database.
  
  **Tags:** craft3, migration, deployment
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_0 on 2020-12-10. Score: 8 | Accepted answer
  
  Something I wish I knew a long time ago, as it has bitten us quite a few times already in the past. Nothing as bad as having an automated deployment process that fails once in a while.
  
  I'm sharing it here, but I believe it would be good to add it to the knowledge base too (<https://craftcms.com/knowledge-base/deployment-best-practices>)
  
  The solution is to split up the structural migration and the content migration.
  
  Pull the update for git and then run
  
  ```
  craft update/composer-install --interactive=0
  craft migrate/all --no-content --interactive=0
  craft project-config/apply --force
  craft migrate --track=content --interactive=0
  
  ```
  
  Pretty straightforward and simple, but I was not aware of the --no-content flag until recently as it not in the command help. I hope it will help somebody in the future!
  
  (The --interactive=0 and --force flags are there because it is an unattended deploy)
  
  > **Comments:**
  > **username_1**: Thanks for pointing this out, Tim. Updated the Knowledge Base article to mention splitting out these steps along with your non-interactive flags.  
  
  ---
  
  