- Use configuration not auto-detection
One problem with the ancestor of
git-deploywas that in a misguided attempt to make things easier it attempted to do a lot of auto-detection. In hindsight this was almost definitely counter productive. It neither made it easier for the users, nor for the developers.
git-deployshould avoid this mistake and use explicit configuration for everything it does .
- Delegate and not implement
git-deployis intended to manage the rollout process, not to actually be responsible for every action. An example would be the process of copying the tree to another host, which will always be the responsibility of a some other tool, although may/will be managed by
The part of the job that
git-deployshould implement is anything involving most aspects of managing git, interacting with the user, configuration, providing locks and logging, etc. Everything else should be delegated.
So for instance a check that the git tree does not contain unpushed commits is something that
git-deployshould know how to do, but it should not directly know how to restart a webserver. It is ok if the
git-deploypackage provides ready made hooks that do things like this, which the user can then configure to be used, but they should never be part of the core behaviour of
- Always design for the complex case
git-deployis intended for managing rolling out many servers in a multi-step process that involves some level of user management. While it does provide tools for simpler scenarios, any feature it implements should generally "fit" into that general process.
- Every rolled out commit should be reachable from the primary branch.
In general git-deploy is designed with the premise that we should always be able to "reach" a rolled out commit from git via git-log. It is possible that this is too restrictive and that it needs to be reconsidered, but it does make life easier as a dev.