Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>The recommended method is this:</p> <ul> <li>Add database changes for your new features to your existing code</li> <li>Make the existing code compatible with the new schema</li> <li>Deploy</li> <li>Add the new features to your codebase</li> <li>Deploy</li> </ul> <p>This means that your database changes are already in place when the code starts to require them. </p> <p>However....</p> <p>There's a couple of issues with this. First that I know of no development shop that is organised enough to be able to handle this, as features just get built ad-hoc, and secondly that you're not really saving anything.</p> <p>Generally speaking, unless your making big changes to a massive database your changes won't take long to apply and are usually over in a couple of seconds which a developer can work around quite happily issuing restarts etc when needed. The risk being that a user might get an error page. If the changes are larger, you have some alternatives. One is using maintenance mode to turn the site off for a few seconds.</p> <p>To be honest, there is no clear cut way for how to handle this nicely as by definition your code needs to be in place for your database changes to start. The best way I've found to approach the problem is to look at each change individually and work out the smoothest path for each on a case by case basis. </p> <p>Rehearsing deployments on a staging environment will mitigate the risk of a deploy going bad, and give you an idea of the impact.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload