Webistrano 1.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 Weiss 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 wrote:

Jonathan Weiss 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:
  http://alpha.project.com/ links to project/current
  http://beta.project.com/ links to project/beta,
  http://www.project.com/ links to project/published,
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 Weiss 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 wrote:

Jonathan Weiss 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

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.

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