[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?

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 :slight_smile:

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 R. 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
[email protected]
http://lists.rubyonrails.org/mailman/listinfo/rails

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

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 :slight_smile:

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 T. 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 :slight_smile:

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 R. 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
[email protected]
http://lists.rubyonrails.org/mailman/listinfo/rails

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

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 T. 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 :slight_smile:

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 R. 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
[email protected]
http://lists.rubyonrails.org/mailman/listinfo/rails

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

Dave T. <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 :slight_smile:

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 P.
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 P. wrote:

Dave T. <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 :slight_smile:

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 P.
http://mapopescu.blogsome.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? :slight_smile:

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.

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 R. [email protected] wrote:

                                 Default: yourserver.com
-c, --components                 If present, copies components
-f=CONFIG_FILE                   Specifies the optional

you will do the pre-deployment stuff.

  • 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 A. 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 R. [email protected] wrote:

                                 Default: yourserver.com
-c, --components                 If present, copies components
-f=CONFIG_FILE                   Specifies the optional

you will do the pre-deployment stuff.

  • J *
    ~

Steve,

I’m including some code that might help you with starting/stopping
lighttpd servers.

Hope it helps,

Adrian M.
HyperX Inc.
Mobile: 801.815.1870
Office: 801.566.0670
[email protected]

9000 S. 45 W.
Sandy, UT 84070