Coder Social home page Coder Social logo

deliver's Introduction

Deliver is a pure bash deployment tool with virtually no dependencies. It only cares about having enough info in the shell environment to do its job. Why add Ruby or Python wrappers on top of system commands when bash was built for this?

Capistrano was just infuriating when you added rvm and bundler into the mix, git-deploy is great for single server, but what if you're running a bunch of auto-scaled clusters (Ruby, node.js etc.)?

Delivering a nodejs service to multiple hosts:

deliver nodejs service to multiple hosts

Delivering deliver to github:pages (very inception-esque):

deliver deliver to github:pages

Strategies is what sets this utility apart from everything else. By default, it comes with strategies for:

You can also add your own, project-specific strategies, or customise existing ones. Read more about deliver strategies.

1 INSTALLATION

1.1 Check out deliver into ~/.deliver.

$ git clone git://github.com/gerhard/deliver.git ~/.deliver

1.2 Add ~/.deliver/bin to your $PATH for access to the deliver command-line utility

$ echo 'export PATH="${PATH}:$HOME/.deliver/bin"' >> ~/.bash_profile
# if using zsh
$ echo 'export PATH="${PATH}:$HOME/.deliver/bin"' >> ~/.zshrc

1.3 Source your shell profile

$ . ~/.bash_profile
# if using zsh
$ . ~/.zshrc 

1.4 Personalize

There are no generators or initializers, you will need to manually create a .deliver/config file in the app's root folder that you want to deliver.

This is a good example:

#!/usr/bin/env bash

APP="events"
HOSTS="ruby-1,ruby-2"
PORT="5000"

2 USAGE

From the root of your project, run:

$ deliver check

deliver check

This will print the most important config settings and ensure that deliver has everything that it needs for a successful run.

Deliver will use the ruby strategy by default. If you want to use a different one, specify it in your .deliver/config file.

To see a list of available strategies:

$ deliver strategies

Read more about deliver strategies

To see all supported options and actions:

$ deliver -h|--help

3 LICENSE

(The MIT license)

Copyright (c) Gerhard Lazu

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

4 CREDITS

Deliver started at GoSquared. It was a place where each of us was free to use their own programming language. As long as the service exposed an API and had decent test coverage, anything went. Yes, even PHP.

INSPIRATION

"Rather than fitting a large number of complex primitives, choose a small number of simple primitives that can be combined in an infinite way to produce complex results. What was left out is more important than what was put in." AT&T - the UNIX operating system

deliver's People

Contributors

cczona avatar gerhard avatar jbt avatar mindreframer avatar shanepelletier avatar thedeveloper avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

deliver's Issues

foreman export upstart tmp

If for some reason the server is restarted, will the upstart scripts automatically start on boot? And is there a reason why it's exported to /tmp rather than /etc/init? Thanks!

Does deliver support rollback?

One thing I expect from deployment tool is ability to easily rollback to previous version in case of some failure (e.g. app deployed to production introduces bug and we want quickly revert to older, working version).

Does deliver supports that?

PORT variable doesn't work

#!/usr/bin/env bash

APP="myapp"
BRANCH="node"
SERVERS="12.34.56.78"
PORT="2222"
STRATEGY="nodejs"

results in:

-----> Ensuring remote is ready to accept git pushes
ssh: connect to host 12.34.56.78 port 22: Connection refused

Why won't it go for the right port? or is there something I am misunderstanding?

Staging / Testing

Just started testing, created config file and a strategy file for composer ... all is fine.

The question I have is how do we handle multiple environments (testing / staging / production)? I can't see anyway to do this other than to completely change the config file each time.

error in git push

remote: error: refusing to update checked out branch: refs/heads/master

I can't push local master to nodejs01-myapp master, it says that it needs to be a bare repo for this to work.

Pre & post function hooks

When delivering, it would be nice if we could notify Campfire of fail/success. We might want to track successful/failed deploys via Graphite, librato metrics or any other endpoint (be it HTTP or some random process listening on a port, locally or remotely).

I'm thinking something along the lines:

declare -f pre_init_app_remotely > /dev/null
if [ "$?" = 0 ]
then
  pre_init_app_remotely
fi

This needs to be a generic function that checks all strategy functions.

Deliver any branch

Currently deliver only supports pushing master branches. As we're abstracting git push, we should be able to push any branch to the remote.

bug in launch

The launch task will not utilize APP_USER. All the other tasks prior to launch will ssh APP_USER@HOST but launch will ssh HOST, causing it to use the local username by default..
I'll try to fix it, but my bash scripting is VERY rusty so I don't know how long it'll take me.

Generated strategy tries to push wrong revision

Think this was introduced in 9579a8c - when delivering using the generated strategy, deliver will attempt to reset the remotes to the revision of the repo before the content was generated, which (as it's on a different branch) doesn't get pushed to the remotes, so fails with a fatal: Could not parse object: '123456...' error.

When SERVERS are missing, deliver doesn't fail

Calista ➜  q git:(master) deliver check

APP             q
APP_ROOT        /Users/gerhard/code/q
STRATEGY        ruby
APP_USER        q
DELIVER_TO      ~q/app
SERVERS         

CAN'T DELIVER, WE'RE MISSING A FEW THINGS

Calista ➜  q git:(master) deliver -V
DELIVERING Q WITH RUBY STRATEGY
Q DELIVERED!

SSH remote hosts key authentication

Initialized empty Git repository in /home/dashboard/app/assets/_lib/d3/.git/
Host key verification failed.
fatal: The remote end hung up unexpectedly

Deliver requires /usr/bin/sh to be bash

__remote() uses ssh syntax, which will evaluate the entire quoted command with env sh, which unfortunately on SmartOS is defined as ksh. The side effect is input redirection fails. It would be nice if __remote could explicitly tell ssh to execute bash and then the command. Not sure how to do this.

Static assets pushed to separate hosts

In a properly distributed service, the front-end servers are separate from the back-end ones. All static assets should be pushed to the front-end servers. This means nothing more than doing the same push as to the back-ends, the difference being that all app-related tasks need dropping. So no dependency installs (npm, gems etc.) & no app restarts.

The next step would be to allow assets to be pushed directly to CDNs. I'm thinking CloudFront to start with (possibly Rackspace Files).

I still need to understand how useful this really is with the new services such as Cloud Flare and Fastly.

Overload-able strategy function

If I need to tweak the setup function from the nodejs strategy, I shouldn't need to create a custom strategy. Overloading specific strategy functions in the config file makes most sense in this scenario.

No sudo when using upstart

Both the ruby & nodejs strategies leverage foreman. Deliver is primarily used on Ubuntu with upstart, and this requires sudo privileges to start/stop upstart jobs.

The way I think this should work is to have a custom foreman upstart template which monitors files in the app itself and takes appropriate action. For example, touch tmp/restart-timeseries-api triggers a restart of /etc/init/timeseries-api.conf.

If foreman fails, the remote command doesn't

In my specific case, if -p option is given an empty argument, foreman command fails silently (double-check this), and the upstart files are not generated. When the resulting conf files are meant to be moved into place, the command fails without an indication as to what exactly happened.

SSH timeout

Handle SSH timeouts properly. Currently, if the SSH can't be executed, the script won't timeout.

Foreman, exports and init control

This is just a quick thought dump:

Should the launch() command be in common, and just use foreman start/status/stop?

Should the launch() command be factored out to common, and have a switch/case for each export format supported by foreman?

Illumos / smf support

Illumos support would be greatly appreciated, for those using SmartOS or the like. Modifications are required for launch to check if `SUPERVISOR="smf", and use the following commands to check status, stop and start a service:

svcs: lists enabled services, even if they're not running. To see all services use 'svcs -a'
svcadm enable <foo>: start the service named <foo>
svcadm disable <foo>: stop the service named <foo>
svcadm restart <foo>: restart the service named <foo>
svcadm clear <foo>: if a service is in maintenance mode, this clears it so it can be enabled
svccfg export <foo>: shows the service manifest about what binary is being run and how

The real work will be in generating a service definition file, which is described here

Overload-able functions

If I need to tweak the setup function from the nodejs strategy, I shouldn't need to create a custom strategy. Overloading specific strategy functions in the config file would make the entire experience a lot neater.

Option to sync / check git remote parity before deliver

If working in teams, it's important to keep your remote repo in sync when deploying releases. As deliver uses forced updates to push refs to the $HOSTS, it risks overwriting the target with an old working copy if the remote was not synced beforehand.

It would be useful to have an option such as $SYNC_REMOTE=origin which will perform a git pull, deliver, git push.

Alternatively, an option to exercise caution by checking your working copy is up to date with remote before a deliver is performed, because you don't always necessarily want deliver and automatically push code you've just pulled from the remote before you check it.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.