Rails - Mar 2006 - [PREVIEW] SmallCap

Somebody suggested SmallCap and that sounds great. This is by no stretch 
of the imagination Capistrano, so it might better be named MicroCap but 
it may be useful to some who have (as I do) modest needs in this regard, 
especially for on-server versioning.

Here''s a preview of the usage:

Usage: ruby smallcap.rb [options]

    -s, --server=SERVER              Copies app to specified server.
                                     Default: yourserver.com
    -u, --user=USER                  User id for server.
                                     Default: youruserid
    -d, --deploy-path=FULLPATHNAME   Specifies the full path on server 
for deployment.
                                     Default: 
/full/path/to/deployment/directory
    -e, --edge_rails                 If present, copies edge or gem 
rails to server.
    -p, --plugins                    If present, copies plugins 
directory to server.
    -c, --components                 If present, copies components 
directory to server.
    -i, --script                     If present, copies script directory 
to server. USE WITH CAUTION
    -g, --config                     If present, copies config directory 
to server. USE WITH CAUTION
    -t, --temp-dir=TMP_DIR           If present, sets the temp directory 
for caching the files prior to
                                     prop. Note that the root 
directories must exist.
                                     Default: System temp directory
    -f=CONFIG_FILE                   Specifies the optional 
configuration file for deployment.
        --configuration-file         Default: deploy.yml

    -h, --help                       Show this help message.

SmallCap defaults to loading a deploy.yml file that specifies your 
server config, so you don''t have to type all this junk each time. 
Additionally, you can have deploy_dev.yml and deploy_test.yml and select 
using -f. Finally, SmallCap loads recipe files in the ./recipes 
directory. I''m still working on the semantics of this, but
it''s where
you will do the pre-deployment stuff.

I''m not ready to put this out ITW yet because it''s not ready
for prime
time, but...comments on what you see? Useful? Not?

-- 
Posted via http://www.ruby-forum.com/.

I like the idea of a simpler deployment solution.  Currently we only  
have one box per application, so I never use the multiple server support  
offered by Capistrano.  However, Capistrano is certainly better than the  
wsadmin script used to deploy WebSphere apps at my day job :)

I see no mention of migrations and server/FCGI process restarts.  If you  
have a plan for those, I''d be happy to give it a whirl.

On Tuesday, March 07, 2006, at 11:22 PM, Steve Ross
wrote:
>Somebody suggested SmallCap and that sounds great. This is by no stretch
>of the imagination Capistrano, so it might better be named MicroCap but
>it may be useful to some who have (as I do) modest needs in this regard,
>especially for on-server versioning.
>
>Here''s a preview of the usage:
>
>Usage: ruby smallcap.rb [options]
>
>    -s, --server=SERVER              Copies app to specified server.
>                                     Default: yourserver.com
>    -u, --user=USER                  User id for server.
>                                     Default: youruserid
>    -d, --deploy-path=FULLPATHNAME   Specifies the full path on server
>for deployment.
>                                     Default:
>/full/path/to/deployment/directory
>    -e, --edge_rails                 If present, copies edge or gem
>rails to server.
>    -p, --plugins                    If present, copies plugins
>directory to server.
>    -c, --components                 If present, copies components
>directory to server.
>    -i, --script                     If present, copies script directory
>to server. USE WITH CAUTION
>    -g, --config                     If present, copies config directory
>to server. USE WITH CAUTION
>    -t, --temp-dir=TMP_DIR           If present, sets the temp directory
>for caching the files prior to
>                                     prop. Note that the root
>directories must exist.
>                                     Default: System temp directory
>    -f=CONFIG_FILE                   Specifies the optional
>configuration file for deployment.
>        --configuration-file         Default: deploy.yml
>
>    -h, --help                       Show this help message.
>
>SmallCap defaults to loading a deploy.yml file that specifies your
>server config, so you don''t have to type all this junk each time.
>Additionally, you can have deploy_dev.yml and deploy_test.yml and select
>using -f. Finally, SmallCap loads recipe files in the ./recipes
>directory. I''m still working on the semantics of this, but
it''s where
>you will do the pre-deployment stuff.
>
>I''m not ready to put this out ITW yet because it''s not
ready for prime
>time, but...comments on what you see? Useful? Not?
>
>--
>Posted via http://www.ruby-forum.com/.
>_______________________________________________
>Rails mailing list
>Rails@lists.rubyonrails.org
>http://lists.rubyonrails.org/mailman/listinfo/rails

Cheers!
--Dave Teare
http://devlists.com - Email list management
http://palmsphere.com - Apps for your hand-held


-- 
Posted with http://DevLists.com.  Sign up and save your time!

You''ve pretty much hit the next work item square on. Here''s my
problem.
I''m not running spinner, so I have no real idea which lighttpd process 
is mine unless I ssh onto the server, do a ps aux|grep lighttpd|grep 
mysitename.

If you are using Apache, at least you have apachectl or graceful.

Any help in this area would totally rock. One of my biggest frustrations 
now is that deployment is not one-touch and I have to do the file 
copying, then kill the server, then restart the server. Doing this all 
in one slug would be great!

I''ll be posting some code RSN :)

Further disclaimer in case anyone missed this: I am NOTNOTNOT trying to 
duplicate Jamis'' great work on Capistrano. I just need less and figured
it was straightforward to write.

Dave Teare wrote:
> I like the idea of a simpler deployment solution.  Currently we only
> have one box per application, so I never use the multiple server support
> offered by Capistrano.  However, Capistrano is certainly better than the
> wsadmin script used to deploy WebSphere apps at my day job :)
> 
> I see no mention of migrations and server/FCGI process restarts.  If you
> have a plan for those, I''d be happy to give it a whirl.
> 
> On Tuesday, March 07, 2006, at 11:22 PM, Steve Ross wrote:
>>                                     Default: yourserver.com
>>    -c, --components                 If present, copies components
>>    -f=CONFIG_FILE                   Specifies the optional
>>you will do the pre-deployment stuff.
>>
>>I''m not ready to put this out ITW yet because it''s not
ready for prime
>>time, but...comments on what you see? Useful? Not?
>>
>>--
>>Posted via http://www.ruby-forum.com/.
>>_______________________________________________
>>Rails mailing list
>>Rails@lists.rubyonrails.org
>>http://lists.rubyonrails.org/mailman/listinfo/rails
> 
> 
> Cheers!
> --Dave Teare
> http://devlists.com - Email list management
> http://palmsphere.com - Apps for your hand-held

-- 
Posted via http://www.ruby-forum.com/.

Skipped content of type multipart/alternative-------------- next part
--------------
#!/bin/sh

# Author: Nathaniel Brown
# Date: December 16, 2005
# URL: http://nshb.net/lighttpd-restart-script.html
# Version: 1.1
# License: GNU GPL 2.0
#
# chkconfig: - 85 12
# description: Infocenter2 Clinical Interface
# Modified by Adrian Madrid for HXM

# Binary Paths
CAT="/bin/cat"
PS="/bin/ps"
SLEEP="/bin/sleep"
BASENAME="/bin/basename"
HTTPD="/usr/local/sbin/lighttpd"

# Modifiy this line for each install
DOMAIN="abc.xyz.com"
PATH="/home/xyz/domains/"$DOMAIN"/"
LIGHTTPD_CONF=$PATH"conf/lighttpd.conf"
PIDFILE=$PATH"run/lighttpd.pid"

PID=0
if [ -e $PIDFILE ]; then
  PID=`$CAT $PIDFILE`
  if [ "x" == "x$PID" ]; then
    PID=0
  fi
fi

case "$1" in
  start)
    if [ 0 -ne $PID ]; then
      running=`$PS --pid $PID | grep $PID`
      if [ $running ]; then
        echo "lighttpd for "$DOMAIN" is already running"
        exit 1
      fi
      rm $PIDFILE
      PID=0
    fi
    $HTTPD -f $LIGHTTPD_CONF
    ;;
  stop)
    if [ 0 -eq $PID ]; then
      echo "lighttpd for "$DOMAIN" was not running"
      exit 1
    fi
    kill $PID
    tries=""
    while [ -e $PIDFILE ]; do
      if [ "x$tries" == "x.........." ]; then
        break
      fi
      $SLEEP 2
      tries=".$tries"
    done
    if [ -e $PIDFILE ]; then
      echo "lighttpd for "$DOMAIN" did not stop gently, killing
the process"
      kill -9 $PID
      rm $PIDFILE
    fi
    ;;
  restart)
    $0 stop
    $0 start
    ;;
  reload)
    if [ 0 -eq $PID ]; then
      echo "lighttpd for "$DOMAIN" was not running"
    fi
    kill -HUP $PID
    ;;
  status)
    if [ 0 -eq $PID ]; then
      echo "lighttpd for "$DOMAIN" is not running"
    fi
    if [ 0 -ne $PID ]; then
      echo "lighttpd for "$DOMAIN" (pid $PID) is running..."
    fi
    ;;
  *)
    echo "Usage: "`$BASENAME $0`"
(start|stop|restart|reload|status)"
    exit 1
    ;;
esac

I''m not going to do an announcement just yet but you can have a look at
the current state of the code by doing an svn co from 
http://opensvn.csie.org/calico_rails/smallcap.

No guarantees about this, but I''ve kicked about five revisions out to a
server to figure out whether it is doing what I want, and it seems ok.

Dave Teare wrote:
> I like the idea of a simpler deployment solution.  Currently we only
> have one box per application, so I never use the multiple server support
> offered by Capistrano.  However, Capistrano is certainly better than the
> wsadmin script used to deploy WebSphere apps at my day job :)
> 
> I see no mention of migrations and server/FCGI process restarts.  If you
> have a plan for those, I''d be happy to give it a whirl.
> 
> On Tuesday, March 07, 2006, at 11:22 PM, Steve Ross wrote:
>>                                     Default: yourserver.com
>>    -c, --components                 If present, copies components
>>    -f=CONFIG_FILE                   Specifies the optional
>>you will do the pre-deployment stuff.
>>
>>I''m not ready to put this out ITW yet because it''s not
ready for prime
>>time, but...comments on what you see? Useful? Not?
>>
>>--
>>Posted via http://www.ruby-forum.com/.
>>_______________________________________________
>>Rails mailing list
>>Rails@lists.rubyonrails.org
>>http://lists.rubyonrails.org/mailman/listinfo/rails
> 
> 
> Cheers!
> --Dave Teare
> http://devlists.com - Email list management
> http://palmsphere.com - Apps for your hand-held

-- 
Posted via http://www.ruby-forum.com/.

Dave Teare <devlists-rubyonrails@...> writes:
> 
> I like the idea of a simpler deployment solution.  Currently we only  
> have one box per application, so I never use the multiple server support  
> offered by Capistrano.  However, Capistrano is certainly better than the  
> wsadmin script used to deploy WebSphere apps at my day job :)
> 
> I see no mention of migrations and server/FCGI process restarts.  If you  
> have a plan for those, I''d be happy to give it a whirl.
Could it be possible that we, the Windows addictive/slaves/fans, will finally be
able to use (a small part of) Capistrano this way? I don''t know if it
is
possible and in your sight.

Anyway, kudos for the idea.

Marius Popescu
http://mapopescu.blogsome.com

Interesting you should mention this. I was thinking about it. I''m 
developing on a Mac which has all kinds of nifty little (and not so 
little) utilities that aren''t available on Windows. However, the
primary
deal killers for Windows are:

- rsync
- ssh
- cp

I do a number of shell commands because OS-native commands like copying 
a tree are far more efficient than a pure Ruby solution. It''s easy to 
replace that though.

rsync is more difficult to replace, but you could eliminate it if you 
were willing to copy the entire tree each time.

ssh is essential if you want to talk directly to your server

This is still a baby, but with input from various platforms, I don''t
see
any reason the x-plat stuff couldn''t be worked out.

Have a look at the current code:

svn co http://opensvn.csie.org/calico_rails/smallcap


Marius Popescu wrote:
> Dave Teare <devlists-rubyonrails@...> writes:
> 
>> 
>> I like the idea of a simpler deployment solution.  Currently we only  
>> have one box per application, so I never use the multiple server
support
>> offered by Capistrano.  However, Capistrano is certainly better than
the
>> wsadmin script used to deploy WebSphere apps at my day job :)
>> 
>> I see no mention of migrations and server/FCGI process restarts.  If
you
>> have a plan for those, I''d be happy to give it a whirl.
> 
> Could it be possible that we, the Windows addictive/slaves/fans, will 
> finally be
> able to use (a small part of) Capistrano this way? I don''t know if
it is
> possible and in your sight.
> 
> Anyway, kudos for the idea.
> 
> Marius Popescu
> http://mapopescu.blogsome.com

-- 
Posted via http://www.ruby-forum.com/.

>  utilities that aren''t available on Windows. However, the primary 
> deal killers for Windows are:
> 
> - rsync
> - ssh
> - cp
if you install MinGW and its associated utilities packages like the MSYS 
and the DTK, you will get all these GNUtils, and they will run native on 
windows. but it is a few steps and definitely not installed by default

certainly sounds like a good argument for writing your deployment 
utility in, i dunno..ruby? how does Capistrano sound for a name? :)

-- 
Posted via http://www.ruby-forum.com/.

While it''s nice to see so much support for easier deployment, I fail to
see the need for it.

Just like setting up a development environment, setting up your 
deployment tools is a thing you only need to do only once.
While Capistrano might be overkill, once configured to your needs 
there''s no need to look back. And as your projects grow, an utility
that
once was overkill might now turn out to meet your needs perfectly.

-- 
Posted via http://www.ruby-forum.com/.

It''s probably too late for a name change, but you might want to bear
in mind that ''SmallCap'' is a fairly common term featured in
investment
spam.

- james

On 3/7/06, Steve Ross <cwdinfo@gmail.com> wrote:
> Somebody suggested SmallCap and that sounds great. This is by no stretch
> of the imagination Capistrano, so it might better be named MicroCap but
> it may be useful to some who have (as I do) modest needs in this regard,
> especially for on-server versioning.
>
> Here''s a preview of the usage:
>
> Usage: ruby smallcap.rb [options]
>
>     -s, --server=SERVER              Copies app to specified server.
>                                      Default: yourserver.com
>     -u, --user=USER                  User id for server.
>                                      Default: youruserid
>     -d, --deploy-path=FULLPATHNAME   Specifies the full path on server
> for deployment.
>                                      Default:
> /full/path/to/deployment/directory
>     -e, --edge_rails                 If present, copies edge or gem
> rails to server.
>     -p, --plugins                    If present, copies plugins
> directory to server.
>     -c, --components                 If present, copies components
> directory to server.
>     -i, --script                     If present, copies script directory
> to server. USE WITH CAUTION
>     -g, --config                     If present, copies config directory
> to server. USE WITH CAUTION
>     -t, --temp-dir=TMP_DIR           If present, sets the temp directory
> for caching the files prior to
>                                      prop. Note that the root
> directories must exist.
>                                      Default: System temp directory
>     -f=CONFIG_FILE                   Specifies the optional
> configuration file for deployment.
>         --configuration-file         Default: deploy.yml
>
>     -h, --help                       Show this help message.
>
> SmallCap defaults to loading a deploy.yml file that specifies your
> server config, so you don''t have to type all this junk each time.
> Additionally, you can have deploy_dev.yml and deploy_test.yml and select
> using -f. Finally, SmallCap loads recipe files in the ./recipes
> directory. I''m still working on the semantics of this, but
it''s where
> you will do the pre-deployment stuff.
>
> I''m not ready to put this out ITW yet because it''s not
ready for prime
> time, but...comments on what you see? Useful? Not?
>
> --
> Posted via http://www.ruby-forum.com/.
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>

--
* J *
  ~

I was ok with "deploy" because it''s easy to type... As you
can see from
this thread, interest has been low to negative, so I''ve put this on a 
very low simmer because there doesn''t seem to be a crying need.

Steve

James Adam wrote:
> It''s probably too late for a name change, but you might want to
bear
> in mind that ''SmallCap'' is a fairly common term featured
in investment
> spam.
> 
> - james
> 
> On 3/7/06, Steve Ross <cwdinfo@gmail.com> wrote:
>>                                      Default: yourserver.com
>>     -c, --components                 If present, copies components
>>     -f=CONFIG_FILE                   Specifies the optional
>> you will do the pre-deployment stuff.
>>
> --
> * J *
>   ~

-- 
Posted via http://www.ruby-forum.com/.