I have a few questions about the deploy task for 1.2 from you all. I would like to hear everyones opinion.
- How far are we trying to take the deploy task this round? I read somewhere the goal is to have something on the level of capistrano. - Do we want to integrate database migrations in to the programmable deploying interface? - Will it have the ability to integrate with source control for tagging, branching, etc. and generate patches to deploy code changes?
This one really interests me because in the past I have used capistrano for managing svn tags, branches and deploying upgrades/ downgrades to code with svn diff and patch. I have always wanted to take it one step further and tie in database migrations to the process because currently I still run the processes a part from each other.
On Wed, Jul 2, 2008 at 5:13 PM, Jonathan Wage <jonw...@gmail.com> wrote: > I have a few questions about the deploy task for 1.2 from you all. I would > like to hear everyones opinion.
> - How far are we trying to take the deploy task this round? I read > somewhere the goal is to have something on the level of capistrano.
or a set of capistrano rules specialised in symfony deployment ?
> - Do we want to integrate database migrations in to the programmable > deploying interface? > - Will it have the ability to integrate with source control for > tagging, branching, etc. and generate patches to deploy code changes?
i think we should start with a very small code base that's capable of : * obtain data (code) from a location * synchronise data on some remote locations * rollback * exposes hooks for doing things prior / after data synchronisation
> This one really interests me because in the past I have used > capistrano for managing svn tags, branches and deploying upgrades/ > downgrades to code with svn diff and patch. I have always wanted to > take it one step further and tie in database migrations to the process > because currently I still run the processes a part from each other.
very interesting subject. i've been experimenting quite a lot too, and (atm) the best system i've found is generating native package for the operating system (rpm, deb, msi, ...). Do you think we should code a deployment task that generate native packages (as python setuptools does more or less) ?
anyway, we need to gather all requirements. i'll set up a wiki page from what we will get from this thread.
here we go :
* database migrations * deployment on multiple servers * code synchronisation protocol abstraction * deployment through gateway servers * run system commands on remote servers * deploy only parts of the projects on servers (n frontend servers, n backend servers, etc) * rollbacks * ...
* database migrations * deployment on multiple servers * code synchronisation protocol abstraction * deployment through gateway servers * run system commands on remote servers * deploy only parts of the projects on servers (n frontend servers, n backend servers, etc) * rollbacks
On Wed, Jul 2, 2008 at 10:56 PM, Tristan Rivoallan
> On Wed, Jul 2, 2008 at 5:13 PM, Jonathan Wage <jonw...@gmail.com> wrote: >> I have a few questions about the deploy task for 1.2 from you all. I would >> like to hear everyones opinion.
>> - How far are we trying to take the deploy task this round? I read >> somewhere the goal is to have something on the level of capistrano.
> or a set of capistrano rules specialised in symfony deployment ?
>> - Do we want to integrate database migrations in to the programmable >> deploying interface?
>> - Will it have the ability to integrate with source control for >> tagging, branching, etc. and generate patches to deploy code changes?
> i think we should start with a very small code base that's capable of : > * obtain data (code) from a location > * synchronise data on some remote locations > * rollback > * exposes hooks for doing things prior / after data synchronisation
>> This one really interests me because in the past I have used >> capistrano for managing svn tags, branches and deploying upgrades/ >> downgrades to code with svn diff and patch. I have always wanted to >> take it one step further and tie in database migrations to the process >> because currently I still run the processes a part from each other.
> very interesting subject. i've been experimenting quite a lot too, and > (atm) the best system i've found is generating native package for the > operating system (rpm, deb, msi, ...). Do you think we should code a > deployment task that generate native packages (as python setuptools > does more or less) ?
> anyway, we need to gather all requirements. i'll set up a wiki page > from what we will get from this thread.
> here we go :
> * database migrations > * deployment on multiple servers > * code synchronisation protocol abstraction > * deployment through gateway servers > * run system commands on remote servers > * deploy only parts of the projects on servers (n frontend servers, n > backend servers, etc) > * rollbacks > * ...
> I have a few questions about the deploy task for 1.2 from you all. I would
> like to hear everyones opinion.
> - How far are we trying to take the deploy task this round? I read
> somewhere the goal is to have something on the level of capistrano.
> - Do we want to integrate database migrations in to the programmable
> deploying interface?
> - Will it have the ability to integrate with source control for
> tagging, branching, etc. and generate patches to deploy code changes?
> This one really interests me because in the past I have used
> capistrano for managing svn tags, branches and deploying upgrades/
> downgrades to code with svn diff and patch. I have always wanted to
> take it one step further and tie in database migrations to the process
> because currently I still run the processes a part from each other.
> Thoughts?
Please consider to support (easy) management of an own pear channel
server for deployment. If we had an easy way to setup and communicate
with a channel server a project update would be as easy as: pear
upgrade mychannel-myproject
And it is easy to integrate database migrations support by pre/post-
installation hooks of the pear installer.
Would be cool to have some tasks for channel-server management.
I'm not sure if "advanced deployment" really is a must for the
framework. It can also be provided by a plugin.
<matthias.nothh...@googlemail.com> wrote: > I'm not sure if "advanced deployment" really is a must for the > framework. It can also be provided by a plugin.
i think that the task should be able to provide usable distribution packages for several distribution systems, but not take care of the distribution itself.
> I have a few questions about the deploy task for 1.2 from you all. I would
> like to hear everyones opinion.
> - How far are we trying to take the deploy task this round? I read
> somewhere the goal is to have something on the level of capistrano.
> - Do we want to integrate database migrations in to the programmable
> deploying interface?
> - Will it have the ability to integrate with source control for
> tagging, branching, etc. and generate patches to deploy code changes?
> This one really interests me because in the past I have used
> capistrano for managing svn tags, branches and deploying upgrades/
> downgrades to code with svn diff and patch. I have always wanted to
> take it one step further and tie in database migrations to the process
> because currently I still run the processes a part from each other.
