Always on Friday.

All files are already in source control and connected to a logged issue once we are ready to build and deploy. From local testing to prod is a bit of a journey, as all code goes into a build to the test environment first. There, everything submitted is thoroughly tested before going into a build to production. Everything developed gets into test, but quality assured code reaches production.

It depends, we run many projects, and for some, our deployment strategy looks similar to what @Innocent described. For some other projects, much older, never upgraded build/deployment procedure, we pick a deployment date. With the recently granted ISO 27001 security certificate, we now must document and deploy new releases a little bit different. More eyes must see, and more hands must approve, which forbids fresh auto deployment from changes on master - but an approval click on GitLab' CI instance. Luckily, not every project is classified dealing with protected data.

We automatically deploy to a dev server when merging a pull request. Then at the end of the sprint we deploy to an acceptance server to allow our client to test it. As soon as the client approves the changes we deploy to production.

We are very careful with when we deploy to production. We only deploy to production in mornings and not on Fridays. This way when things break we can quickly fix them.

In my company deploy is every 2 weeks, on monday morning, we made 2 weeks sprints.

At a past job - we never changed code on the 15th or 30 of the month (industry specific dates) or on a Friday before a holiday

On my side project, I generally pick a day I think I'll be done with my changes and deploy on the closest Sunday after 8pm to avoid anyone being on the site.