# \[ANN\] Webistrano 1.1 **URL:** \ **Category:** Rails\ **Created:** [September 28, 2007, 3:17pm UTC](https://www.ruby-forum.com/t/ann-webistrano-1-1/115785 "2007-09-28T15:17:35Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![waddilove](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/w/b5ac83/32.png) [@waddilove](https://www.ruby-forum.com/u/waddilove)\ **Post date:** [September 28, 2007, 3:17pm UTC](https://www.ruby-forum.com/t/ann-webistrano-1-1/115785/1 "2007-09-28T15:17:35Z")
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/](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://webistrano.rubyforge.org/svn/trunk](http://webistrano.rubyforge.org/svn/trunk) [http://labs.peritor.com/svn/webistrano/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](http://labs.peritor.com/webistrano/attachment/wiki/Download/webistrano-1.1.zip?format=raw) Jonathan – Jonathan W. [http://blog.innerewut.de](http://blog.innerewut.de) ---
**Author:** ![waddilove](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/w/b5ac83/32.png) [@waddilove](https://www.ruby-forum.com/u/waddilove)\ **Post date:** [September 28, 2007, 5:11pm UTC](https://www.ruby-forum.com/t/ann-webistrano-1-1/115785/2 "2007-09-28T17:11:58Z")
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/](http://alpha.project.com/) links to project/current with RAILS\_ENV=development [http://beta.project.com/](http://beta.project.com/) links to project/beta, which symlinks to project/releases/2007…42 with RAILS\_ENV=production [http://www.project.com/](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/](http://www.oreilly.com/catalog/9780596510657/) ^ assert\_xpath ---
**Author:** ![waddilove](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/w/b5ac83/32.png) [@waddilove](https://www.ruby-forum.com/u/waddilove)\ **Post date:** [September 28, 2007, 5:20pm UTC](https://www.ruby-forum.com/t/ann-webistrano-1-1/115785/3 "2007-09-28T17:20:09Z")
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](http://svn)…/trunk beta: [http://svn](http://svn)…/releases/2 prod: [http://svn](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://labs.peritor.com/webistrano/wiki/Screencasts) [http://blog.innerewut.de/files/webistrano/screencasts/webistrano.mov](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](http://blog.innerewut.de) ---
**Author:** ![waddilove](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/w/b5ac83/32.png) [@waddilove](https://www.ruby-forum.com/u/waddilove)\ **Post date:** [September 29, 2007, 4:56pm UTC](https://www.ruby-forum.com/t/ann-webistrano-1-1/115785/4 "2007-09-29T16:56:33Z")
Jonathan W. wrote: > and the repository variable > > alpha:[http://svn](http://svn)…/trunk > beta:[http://svn](http://svn)…/releases/2 > prod:[http://svn](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 ---
**Author:** ![waddilove](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/w/b5ac83/32.png) [@waddilove](https://www.ruby-forum.com/u/waddilove)\ **Post date:** [September 30, 2007, 10:05am UTC](https://www.ruby-forum.com/t/ann-webistrano-1-1/115785/5 "2007-09-30T10:05:54Z")
> 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](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. ---
**Author:** ![waddilove](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/w/b5ac83/32.png) [@waddilove](https://www.ruby-forum.com/u/waddilove)\ **Post date:** [September 29, 2007, 5:49pm UTC](https://www.ruby-forum.com/t/ann-webistrano-1-1/115785/6 "2007-09-29T17:49:36Z")
Phlip wrote: > Jonathan W. wrote: > > > and the repository variable > > > > alpha:[http://svn](http://svn)…/trunk > > beta:[http://svn](http://svn)…/releases/2 > > prod:[http://svn](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](http://blog.innerewut.de) ---
**Author:** ![waddilove](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/w/b5ac83/32.png) [@waddilove](https://www.ruby-forum.com/u/waddilove)\ **Post date:** [September 30, 2007, 11:18am UTC](https://www.ruby-forum.com/t/ann-webistrano-1-1/115785/7 "2007-09-30T11:18:58Z")
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](http://blog.innerewut.de)