ivandokov / depy Goto Github PK

If the shared directory is nested it is not working because it is trying to move nested path to nested path with mv

Now the config directory is called depy and it bugs the autocomplete of the depy binary. When you type depy tab tab does not autocomplete next arguments because of the collision. A space is required which us annoying.

Currently the release name is generated on the deployer side based on the UTC date, but this is unreliable method. The server should provide the release name.

A possible solution is to have a plain text file on the server with integer which is the release name and increment it for each release.

I think the process should be like this:

• Copy-paste the latest release on the server to be current (not linking as current)
• Rsync the local files to this new release
• Link it as current
  ...

When the ssh connection fails mid-deploy it will leave the newly uploaded release unreleased and in a not working state. This is not an issue for the target server as the unfinished release is not linked as current, but it is an issue for the rollback functionality as the list of previous releases will include the broken one.

A good solution for the issue is to create a temporary file with the name of the current release before the extraction of the package and remove the file once it is linked as current release.

Add functionality for tagging releases.
This can be implemented with a simple plain text file on the server.

The recent change of the releases names introduced a but with the cleanup of old releases. The sorting is not using a natural sort but an alphabetical one and release with name 10 is considered older than 9, which is not true. Previously this was not the case as the release names were timestamps with the same length and any kind of sort was correct.

Consider to rewrite the entire thing on go language for v1.0

Provide bash autocomplete functionality

deploy_target does not zip the targets contents but the entire path to the target

At the moment multiple deployments are possible.
Introducing deployment lock will guarantee expected behaviour.
It could be based on checking of the existence of a file.

Force deploy must be available since the deploy could fail and the lock file will stay on the server.

Depy should have updates checker and self updater.

This is a nice starting point: http://stackoverflow.com/questions/8595751/is-this-a-valid-self-update-approach-for-a-bash-script

Currently most Linux distributions do not have installed zip by default and this is unnecessary dependency when tar.gz can be created on most/any UNIX system.

At the moment if you do not have ssh access and try to run depy setup production it will fail but still print error message saying:

[email protected]: Permission denied (publickey).
Server production does not have unzip installed

Add option to deploy a specific directory, not the whole current directory because it will be easier for projects such as Angular where you get a dist directory and this is the only one which you should deploy to the server.

This mode should print all of the commands/information from the process.

At the moment the code exits with error if the deployment target is missing. This does not give a chance for the pre-hook to generate the target directory. For example when deploying Angular app it has to run ng build prod and create a dist directory which will be deployed.

Most of the checks on the remote server are done with multiple ssh calls.
They can be combined in a single or fewer calls using Bash Heredoc

ssh host << EOF
  command1
  command2
  if []; then
    command3
  fi
EOF

This will increase the speed of the entire process as less calls will be done over the network.

Add functionality to mark releases as frozen and ignore them when the cleanup is done.
Preferably #14 should be implemented first, but not mandatory as freezing release should be done by name or tag.

Parallel deployment to multiple servers will be really useful feature.
There should be spawned subprocesses which handle each server deployment.

At the moment we have a single ignores array with regex patterns to exclude directories and files from the release. When creating a full release the files are archived with zip but when incremental release is created the files are transferred with rsync to match the different files only. Both tools use the same ignores array with patterns but their regex parsers are different and the set of files is not the same for both releases.

If you have for example an .env file that is added to shared but at the current deployment you do not have it locally it will not be linked from previous releases.