PHPloy
PHPloy copied to clipboard
banago
Atomic deployments
PHPloy updates the SHA hash in .revision on the server even when there were errors while uploading files, for example because they are not readable. This is not consistent and may lead to wrong deploys that are not easily recognizable because on the next run PHPloy compares the SHA hash from .revision with the current SHA of the repo and thinks the server is in sync, which is not true.
The best way would be to implement it like a transaction: If the uploading of any file fails, rollback to the previous commit (before the update) to keep the system in a consistent state, and keep that SHA1 in .revision. The user has the chance to fix the problem with his local files (hopefully) and retry.
But i know how hard it is to implement transactions. But if the existing rollback mechanism would work reliably, it would be easier: Before updating .revision with the new SHA1, check if all files were uploaded OK. If not, read the (still old) SHA1 from .revision and start a rollback to that SHA1. If all files were transferred OK, update the SHA1 in .revision to the new one.
Or fist upload to temporary directory and check that all files are on the place. After that test write permissions to original files and then switch and change .revision file.
Implement some very basic building system. Because uploading code directly brakes live website at some points. Its very cool while u are deploying to stage or any dev server, but for live u need to use smth that has builds "Phing" or "Capistrano" just because users can use website while website is being deployed.
I love this tool, because Capistrano and Phing is to complicated for small projects, u do not need complicated building or make automated DB migrations while working on small projects, but when uploading brakes ur code and can mess a database data its a bad thing.
@dl1ely and @Schnoop seems this feature has enough demand now to make it into PHPloy. Would any one of you guys like to implement a basic version of this?
There a several ways to implement this feature.
- versions folder
- Upload as filename.php.tmp and then rename to filename.php
- ....
Also: What deploy is it worth to create a new version for? Not for every minor change there has to be full deploy.
Every new version has to be a full deploy as there is no code base to create a diff for.
Let's assume that we have a new version on daily base, and the version from today is active via Symlink. When we roll a new deploy at the same day, we will eventually break our website, because the version is in production.
There's is a need for a good concept, as this feature will break your effort that PHPloy is a lightweight, and fast (through git version diff) deployment script.
@Schnoop My suggestion is second option. Second option will be fast and easy to manage, furthermore it can be the standard way to upload new revisions. It is significant faster to upload the files as filename.extension.hashsum and first after all files has been uploaded it will initiate a move (rename) on all files. First option will not be fast because by design, it will need to upload all files to make it possible to "deploy a new version".
Great input guys, thanks very much. I also lean toward the renaming solution. It's much easier to implement and is lightweight. I suggest however that we don't make it default behaviour, since most deployment happens in staging environments, but turn it on in two ways:
- On command line by:
phploy --atomic - On configuration file by:
atomic = on
So you can use it when you need it in terminal or set it and forget it on the .ini file, especially in live servers. What do you think?
The proposed atomic option looks great!
I assume that if the rename/upload fails then it would also delete all those tmp files? Otherwise, there would be lots of orphaned .tmp files scattered across the remote server
