[ANN] Webistrano 1.1

Rails
1

Webistrano is a Web UI for managing Capistrano deployments. It lets you
manage projects and their stages like test, production, and staging with
different settings.

It took a little longer because we got some feedback at Rails Conf
Europe that we incorporated.

Further Webistrano now has its new home and own Trac/Wiki/Ticketsystem
at the Peritor Labs:

http://labs.peritor.com/webistrano/

This means that the Subversion URL also changed. If you tracked
Webistrano through svn, please switch to new URL:

svn switch --relocate http://webistrano.rubyforge.org/svn/trunk/
http://webistrano.rubyforge.org/svn/trunk
http://labs.peritor.com/svn/webistrano/trunk

The major change in version 1.1 is a new shiny UI by the curtsy of
Marcus Lamer.

Further recipes are now associated to stages and not projects anymore so
that different stages of a project can have different recipes.
Webistrano now also set two variables inside recipes by default. Those
two variables ( :webistrano_project and :webistrano_stage) are set to
the project and stage name and can be used to do some decision making
inside your recipes.

Upgrading from 1.0 is quite easy, just download the new version, copy
your configuration files over and upgrade the database:

RAILS_ENV=production rake db:migrate

The roadmap for the next versions includes some basic monitoring
capabilities and some form of permission management that lets you manage
which user can deploy which projects and so on.

The screencasts have not been updated yet but the content they provide
is still valid, the only change is that recipes now belong to stages.

Direct download link:

http://labs.peritor.com/webistrano/attachment/wiki/Download/webistrano-1.1.zip?format=raw

Jonathan

–
Jonathan W.
http://blog.innerewut.de

2

Jonathan W. wrote:

Webistrano is a Web UI for managing Capistrano deployments. It lets you
manage projects and their stages like test, production, and staging with
different settings.

We need a Capistranoid system to do this:

cap deploy goes to project/current

http://alpha.project.com/ links to project/current
with RAILS_ENV=development

http://beta.project.com/ links to project/beta,
which symlinks to project/releases/2007…42
with RAILS_ENV=production

http://www.project.com/ links to project/published,
which symlinks to project/releases/2007…41
with RAILS_ENV=production

That way, developers deploy at whim, and managers move a given release
thru the system to published as they test and bless versions.
(Naturally, the system ought to provide database steps, too.)

Is that what you mean? How do we get all that?

–
Phlip
http://www.oreilly.com/catalog/9780596510657/
^ assert_xpath

3

Phlip wrote:

Is that what you mean? How do we get all that?

This is exactly what Webistrano is for. Makeing complicated multi-stage
Capistrano environments easy through a Web UI.

Basically you would create one project in Webistrano and then have 3
different stages (alpha, beta, prod). Each stage would overrive the
deploy_to variable:

alpha: /srv/project/alpha
beta: /srv/project/beta
prod: /srv/project/www

and the repository variable

alpha: http://svn…/trunk
beta: http://svn…/releases/2
prod: http://svn…/releases/1

The different Rails env would also be set as a variable or inside your
mongrel configuration.

See also the screencast for version 1.0. The UI changed but the basics
are the same:

http://labs.peritor.com/webistrano/wiki/Screencasts

http://blog.innerewut.de/files/webistrano/screencasts/webistrano.mov

Your folks would then only have to click on the deploy button for each
stage.

Jonathan

–
Jonathan W.
http://blog.innerewut.de

4

Jonathan W. wrote:

and the repository variable

alpha:http://svn…/trunk
beta:http://svn…/releases/2
prod:http://svn…/releases/1

I want to use only one svn lineage (I abhor code forks), and to
symlink the beta and prod domains to previous entries in the one
releases/2007* folder. This implies that the public version is the
exact same source files as passed alpha and beta tests. We would bless
a version by moving the symlink to it.

Is this what your lecture claims Capistrano makes hard? Or do you
imply that using multiple SVN drops is hard?

The different Rails env would also be set as a variable or inside your
mongrel configuration.

lighttp.

–
Phlip

5

In general handling different environments of the same project with
Capistrano is not trivial. Webistrano tries to make this easy.

Have you tried Multistage?

http://weblog.jamisbuck.org/2007/7/23/capistrano-multistage

…is a good explanation. You can then use a

set :rails_env, ‘staging’

…or whatever, and use this in your server start / stop / restart
bits.

6

Phlip wrote:

Jonathan W. wrote:

and the repository variable

alpha:http://svn…/trunk
beta:http://svn…/releases/2
prod:http://svn…/releases/1

I want to use only one svn lineage (I abhor code forks),

You can argue a lot how the right way to do this is, but in my
experience using different branches is the way to go. As long as you do
not commit to this branch/tag you have exactly the same code without any
hacks like your symlink stuff. Further you can backport bug-fixes and
important patches.

and to
symlink the beta and prod domains to previous entries in the one
releases/2007* folder. This implies that the public version is the
exact same source files as passed alpha and beta tests. We would bless
a version by moving the symlink to it.

You can easily do this with Webistrano, just define a custom task for
updating the symlink.

Is this what your lecture claims Capistrano makes hard? Or do you
imply that using multiple SVN drops is hard?

In general handling different environments of the same project with
Capistrano is not trivial. Webistrano tries to make this easy.

The different Rails env would also be set as a variable or inside your
mongrel configuration.

lighttp.

Should make no difference, you would then set the env in your lighttpd
config.

Jonathan

–
Jonathan W.
http://blog.innerewut.de

7

andrewbruce wrote:

In general handling different environments of the same project with
Capistrano is not trivial. Webistrano tries to make this easy.

Have you tried Multistage?

Yes, but the management of stages is not easy. Maybe you want other
people to deploy the staging and testing envs and those people are not
friends of the CLI. Or you do not want to remember the many CLI args to
capistrano for deploying the test env to a special set of servers. Or
you want to know who deployed which version when to which servers.

This is where Webistrano comes in.

It is more than a GUI for Webistrano and not a replacement for it.

Jonathan

–
Jonathan W.
http://blog.innerewut.de