Not sure if this is the right place for this but...
After deploying an update to the project.yml file I don't think it should take down the front end. I understand that it errors because there are changes that need syncing, but it shouldn't have that kind of consequence, especially in a production environment.
I'm wondering if there's a reason behind the current behaviour and/or if there is scope to change it?
Thanks ✌️
I believe because it's a DB related action, there isn't really a lot of choice in the matter. You can however automatically have your project.yaml synchronised during your deployment process, so this is done automatically and doesn't leave your production site waiting for this to manually happen.
If you use composer, you can add the Craft CLI command to your post-install-cmd section. Or have it run as part of your deployment pipeline.
@jamesmacwhite Thanks for that, I didn't realise there was a way to automate it, definitely going to add that to our pipeline 🥳
I totally see where you're coming from but I still think it shouldn't/doesn't need to take the frontend down. Applying the project config changes is what alters the database, so before they're applied the site should be able to run with the DB in the state it was pre-deployment.
I understand there will be situations where you push things like template changes that rely on fields in the project config, or maybe plugin updates, but I would have thought in the majority of cases there would be no need to completely kill the frontend.
Maybe I'm thinking about it all wrong
@alexjcollins No worries. I only recently discovered it as well! Craft CLI is awesome.
I totally understand your point, it certainly might seem overkill in some cases. I'm sure the devs will chime in on their views on it. Given it's generally a new feature I'm sure it will evolve overtime and perhaps this is an area which might be looked at.
Same reason that the site goes down if there are pending Craft/plugin migrations – because there’s a decent chance that you are going to get other errors until the changes have been synced.
For example, let’s say you are pushing an update that includes a new field, and the templates have been updated to output the field’s value. If the field doesn’t actually exist yet, you will get an UnknownPropertyException with a 500 status. So it would be better to just take the site down and offer 503 (Unavailable) responses, until we know Craft is ready to resume serving the site.
And yeah, you should shorten that window by automatically running craft migrate/all and craft project-config/sync after deployments.
Most helpful comment
I believe because it's a DB related action, there isn't really a lot of choice in the matter. You can however automatically have your project.yaml synchronised during your deployment process, so this is done automatically and doesn't leave your production site waiting for this to manually happen.
If you use composer, you can add the Craft CLI command to your post-install-cmd section. Or have it run as part of your deployment pipeline.