fredistrano plugins?

[zemi]

Hi there,
I was looking for deployment from SVN solution and came across with
Fredistrano. It's very nice project and I think I can say the same
about the code.
It creates nice foundation for further improvements and I was thinking
particularly about these:
before/afterScipts as plugins - plugin system will allow more
flexibility then current way (one after/beforeScript and some other
options like rename .prd files or backup). All of these options could
be implemented as plugins. There can be some build-in plugins coming
with fredistrano, but at the same time others will be able to
implement and plug in their own easily.
Examples of existing plugins can be: run-script, backup, rename-files
(prd).
You'll be able to run project plugins (stored in .fredistrano
directory) or have server plugins. Example of server plugin can be:
create-apache-conf, restart-apache or create-dns-record and they will
be 'server-oriented' (not 'project-oriented') and installed in
fredistrano installation.
An important thing fredistrano should support is passing project
parameters to plugins/scripts (project name, abs path, svn url, ...);
and be able to set custom attributes for a project.

Hope this makes some sense. What do you think? Is there some
possibility how to contribute to the project? I've installed
fredistrano on our testing server in the office and I'm able to help
with improvements.

Regards,
zemi

[euphrate_ylb]

Hi zemi,

Thank you for helping us to improve fredistrano. We really appreciate
the fact that you took some time to write us this interesting
proposal.

For a long term vision, the current architecture of fredistrano is
certainly unsatisfying. Indeed, the finalize step is not implemented
in a generic way. The more features we add, the messier it gets...
This problem is due to the origin of fredistrano. Initially, it was a
specific project for the company we are working in. When we
"opensourced" the application, we simply tried to make it a little bit
more generic. Unfortunately,we never took the time to think
fredistrano as an open deployment tool.

Therefore, your plugin approach would greatly benefit the application
and its users. First of all, extending fredistrano wouldn't be a
burden anymore considering that all new features are new plugins.
Then, we could create a community of users who design and share new
plugins. So yes, it really makes sense to me!

Actually, we also had the same idea but expressed slightly
differently. We wanted to create a customizable deployment process in
which users may compose from available steps their own process. A
prerequisite of that is the isolation of each step through
standardized interfaces that is to say "pluginize" each step.

However, our main problem with fredistrano is our lack of time.
Currently, fredistrano is after-after-hours project. Beside solving
critical bugs, we don't have much time to implement new features. From
the feedbacks, the next two key features to be implemented have
already been selected:
1. GIT integration
2. SQL deployment (with rollback)
Therefore, modifying the core classes of fredistrano (which is a time
consuming task with minor short term impact on the community) is not
going to happen soon. Nevertheless, it would be a great milestone for
the 2.0 release.

Moreover, our goal is not to design a web version of existing powerful
build tool (e.g. ant, maven). We must be cautious not to create a
solution that will offer the same functionalities with a lower
reliability (fredistrano is a small project).

Concerning your contribution, you can help us in many ways: donation
(just kidding ;), help us for the translations, report bugs, make
proposals like you just did, test new features before we release then
to the community, or write some code if you feel comfortable with
PHP.

I hope my answer is as clear as your initial message. Happy orbiting
with Fredistrano!

Best regards,

Yann Le Blevec