Ocramius
commented
7 years ago @gabbydgab this is something for deployment tools, not for the framework itself.
0-downtime deployments are brutally simple with pretty much any framework (including ZF2, ZF3 and expressive, which you mentioned in https://github.com/zendframework/zend-expressive-skeleton/pull/54#issuecomment-269746906) if they only involve code deployments (DB migrations are a different story).
mkdir deployment/2016-12-30_11-59-00-0beec7b5ea3f0fdbc95d0dd47f3c5bc275da8a33
cd deployment/2016-12-30_11-59-00-0beec7b5ea3f0fdbc95d0dd47f3c5bc275da8a33
# do your thing - copy files from a source, install an RPM, run git - pick your poison
cd ../..
unlink production
ln -s deployment/2016-12-30_11-59-00-0beec7b5ea3f0fdbc95d0dd47f3c5bc275da8a33 productionThat's it.
Please note that most mature deployment tools do it this way.
Closing here - this is not a framework issue.
How can you set that X module is in maintenance mode, as it's services is used by Y and Z modules? in an 11-th hour production issue with zero-downtime.
What is the appropriate way in solving issues in a specific module in your application? Aside from disabling the module completely in the modules config then release a patch for it.
Is there any article in providing tips how to make sure this is achievable/doable but with more work developing this type of application.
With the advent of dependency management using composer, we cannot tell that what we include in our module is secured - unless proven and tested. Example of it is this issue on the PHPMailer package https://legalhackers.com/advisories/PHPMailer-Exploit-Remote-Code-Exec-CVE-2016-10033-Vuln.html
IMPOV, It's our problem due to our decision in including these package as dependency. And clients should not suffer from the decisions that we made that's why we need to be able to handle zero-downtime in a 11-th hour production patches. .
Appreciate your thoughts about this matter and how can we improve this framework and as developers.