desarrollo, test, produccion
socendani
Quisiera proponer al equipo alguna idea sobre lo que me es complejo de
kumbia
No consigo una sintonía ideal en el sistema kumbiaphp para el cambio
de entornos.
Quizás no lo hago correctamente, encantado de que me guiéis un pelín..
La situación habitual es que programamos en local y subimos las
páginas por ftp al servidor de test y al servidor de producción. Lo
que implica que no puede haber diferencias entre los ficheros (ni
siquiera los ini) porque ya me ha pasado que he sobreescrito el
config.ini y ... petada de conexión..
En la wiki oficial hay esto:
http://wiki.kumbiaphp.com/Pasar_a_produccion
pero no lo veo práctico, porque los ficheros se suben varias veces (y
ahora me tengo que estar acordando de oculatr los.ini) y además, solo
concibe producción: on/off.
Mi ideal sería:
* databases.ini => [etiquetas_necesarias] por ejemplo: [development].
[testing].[production], etc...
* config.ini =>[etiquetas_necesarias] por ejemplo: [development].
[testing].[production], etc...
* En el public/index.php poder definir el estado del entorno
dinámicamente por switch case del HTTP_SERVER, que permita definir
las urls de dev, test, production o lo que sea..
y al ejecutar el kumbia/bootstrap escoga los parámetros de la label
definida anteriormente de forma dinámica..
* la activación del cacheo y el log podría activarse con variables
propias en el config.ini en vez del concepto: production = Off / On
Bueno, solo es una idea...
Para solventarlo, modificaré el bootstrap, para que me permita tener
config.inis diferentes o algo por el estilo.. pero sería ideal que
fuera más parametrizable y no tocar el core.
Mis felicitaciones al trabajo de kumbiaphp.. el arranque de un site
con kumbia es realmente rápido y cómodo, aunque la última descarga de
*bzr me falló algo con el PDO y tuve que tirar de la beta2 de
kumbia.svn.sourceforge.net pero buen... que genial todo!
dani
Deivinson Tejeda
--
Viva KumbiaPHP Framework!
http://www.kumbiaphp.com/
Ha recibido este mensaje porque está suscrito a Grupo "KumbiaPHP Framework" de Grupos de Google.
Para obtener más opciones, visita este grupo en http://groups.google.com/group/kumbia?hl=es.
--
Deivinson Tejeda (CaChi)
KumbiaPHP Framework Developer
http://www.kumbiaphp.com
Twitter @DeivinsonTejeda
Deivinson Tejeda
Deivinson Tejeda
socendani
glup! Creo que no me he explicado bien, sorry.. .
el objetivo que planteo es que el 100% de los ficheros INI, PHP,
PHTML (vamos todo, excepto quizás lo cacheable) estén idénticos en
entorno PROD, DEV, TEST, PRUEBAS1, PRUEBAS2, para que pueda hacer ftp
para arriba y abajo sin pensar en que el fichero "config.ini" del
servidor X está diferente al "config.ini" del servidor de test,
prueba1, prueba2...
Entiendo que el proceso actual hacemos el desarrollo en local, por
ejemplo y subimos todo a un host...
vamos al host y modificamos el config.ini (producción=on ->se activa
cache, database=db_de_produccion, y otras cosas..), etc..
desde ese momento, debo recordar no sobreescribir el "config.ini"
imagina, si además ponemos entornos extras, servidores, hosts
diferentes, testing, bd_1, bd_2_especial_charset ..
crear vhost en desarollo es tedioso.. ahora mismo estoy con 33
projectos (3 de ellos con kumbia) y necesito el dinamismo del
public_path, que además, en mi caso, para entornos de producción
instauraré un static_path para todos los projectos con enlaces fijos
para js, img, css comunes.. etc..
bueno.. os dejo que seguro que ya os he dado mucho la tabarra
ta lueg!
dani
On 3 mar, 15:07, Deivinson Tejeda <deivinsontej...@kumbiaphp.com>
wrote:
> define('PUBLIC_PATH', '/') es suficiente si se trabaja con vhost y el
> DocumentRoot del dominio este apuntando al dir public/ de tu app :-)
>
> Recuerda algo KumbiaPHP no coloca limites, somos nosotros mismo con un poco
> de imaginación que damos juegos a los elementos disponibles,
>
> ¡Éxitos!
>
>
>
>
>
>
>
>
>
> > Bueno en ningún momento haz de tocar el core para llevar tu app a
> > production, a nivel de los .ini (config.ini) solo con indicar que que se
> > conecte a databases = production KumbiaPHP vera los datos de conexión dentro
> > de [production], no hay mas nada que tocar en los .ini respecto a esto...
>
> > Lo de las URls a nivel de tus server es mas simple de lo que dices, con
> > solo obviar el calculo de la constante PUBLIC_PATH esto se resuelve
> > define('PUBLIC_PATH', 'http://dominio.com/');(y comentar las lineas donde
> > se hace el calculo).
>
> > Recordar que KumbiaPHP hace esto para que la instalación sea mas cómoda.
>
> > El log y cacheo son cosas distintas, asi que si creas log
> > ellos seguirán generándose al igual que si haces cache. La única diferencia
> > es que estando en modo production=off KumbiaPHP no generara la cache porque
> > asumes que estas desarrollando y no veras los cambios.
>
> > En el futuro release, ya hay disponible un bootstrap para la app, en donde
> > se podrá parametrizar muchas mas cosas que como desarrollador queramos.
>
> > ¡Éxitos!
>
> > La idea es tener un entorno local tan parecido como el de
> >> production quizás la diferencia mas marcado es habilitar todos los errores y
> >> no tener un ambiente para tener alto rendimiento (cache, apc, etc..)
>
> >> Incluso recomiendo tener vhost asi simulas como si tu aplicación estuviese
> >> funcionando en tu dominio y no en
> >>http://dominio.local/controller/action/esto es un vhost.
>
> >> 2011/3/3 socendani <socend...@gmail.com>
raul montejano rodriguez
en este segundo correo tampoco te explicas del todo bien:
static_path para que ?
las rutas de los css,img,js son relativas al dominio.
tedioso los vhost o quieres decir que no sabes hacerlo, porque solo hay
que tocar dos archivos y en uno de ellos solo una linea.
a lo que dices del planteo 100% son solo 3 archivos los que no tienes
que subir y editar desde el server. dababases.ini, config.ini e
index.php de public. con filtrar esos archivos en el filezilla para que
no te los subas es suficiente.
ahora que tambien se podrian duplicar esas lineas para tener config
preparada para dev y pro y hacer lo que dices.
El 03/03/11 15:41, socendani escribi�:
> Uola!
> glup! Creo que no me he explicado bien, sorry.. .
>
> el objetivo que planteo es que el 100% de los ficheros INI, PHP,
> PHTML (vamos todo, excepto quiz�s lo cacheable) est�n id�nticos en
> entorno PROD, DEV, TEST, PRUEBAS1, PRUEBAS2, para que pueda hacer ftp
> para arriba y abajo sin pensar en que el fichero "config.ini" del
> servidor X est� diferente al "config.ini" del servidor de test,
> prueba1, prueba2...
>
> Entiendo que el proceso actual hacemos el desarrollo en local, por
> ejemplo y subimos todo a un host...
> vamos al host y modificamos el config.ini (producci�n=on ->se activa
> cache, database=db_de_produccion, y otras cosas..), etc..
> desde ese momento, debo recordar no sobreescribir el "config.ini"
> imagina, si adem�s ponemos entornos extras, servidores, hosts
> diferentes, testing, bd_1, bd_2_especial_charset ..
>
> crear vhost en desarollo es tedioso.. ahora mismo estoy con 33
> projectos (3 de ellos con kumbia) y necesito el dinamismo del
> public_path, que adem�s, en mi caso, para entornos de producci�n
> instaurar� un static_path para todos los projectos con enlaces fijos
> para js, img, css comunes.. etc..
>
> bueno.. os dejo que seguro que ya os he dado mucho la tabarra
> ta lueg!
> dani
>
>
>
>
> On 3 mar, 15:07, Deivinson Tejeda<deivinsontej...@kumbiaphp.com>
> wrote:
>> Incluso en la definici�n de la constante PUBLIC_PATH, con hacer lo siguiente
>> define('PUBLIC_PATH', '/') es suficiente si se trabaja con vhost y el
>> DocumentRoot del dominio este apuntando al dir public/ de tu app :-)
>>
>> Recuerda algo KumbiaPHP no coloca limites, somos nosotros mismo con un poco
>> de imaginaci�n que damos juegos a los elementos disponibles,
>>
>> ��xitos!
>>
>> 2011/3/3 Deivinson Tejeda<deivinsontej...@kumbiaphp.com>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>> Bueno en ning�n momento haz de tocar el core para llevar tu app a
>>> production, a nivel de los .ini (config.ini) solo con indicar que que se
>>> conecte a databases = production KumbiaPHP vera los datos de conexi�n dentro
>>> de [production], no hay mas nada que tocar en los .ini respecto a esto...
>>
>>> Lo de las URls a nivel de tus server es mas simple de lo que dices, con
>>> solo obviar el calculo de la constante PUBLIC_PATH esto se resuelve
>>> define('PUBLIC_PATH', 'http://dominio.com/');(y comentar las lineas donde
>>> se hace el calculo).
>>
>>> Recordar que KumbiaPHP hace esto para que la instalaci�n sea mas c�moda.
>>
>>> El log y cacheo son cosas distintas, asi que si creas log
>>> ellos seguir�n gener�ndose al igual que si haces cache. La �nica diferencia
>>> es que estando en modo production=off KumbiaPHP no generara la cache porque
>>> asumes que estas desarrollando y no veras los cambios.
>>
>>> En el futuro release, ya hay disponible un bootstrap para la app, en donde
>>> se podr� parametrizar muchas mas cosas que como desarrollador queramos.
>>
>>> ��xitos!
>>
>>> 2011/3/3 Deivinson Tejeda<deivinsontej...@kumbiaphp.com>
>>
>>> La idea es tener un entorno local tan parecido como el de
>>>> production quiz�s la diferencia mas marcado es habilitar todos los errores y
>>>> no tener un ambiente para tener alto rendimiento (cache, apc, etc..)
>>
>>>> Incluso recomiendo tener vhost asi simulas como si tu aplicaci�n estuviese
>>>> funcionando en tu dominio y no en
>>>> http://localhost/xxxx/controller/action/mejor seria tenerlo en local
>>>> http://dominio.local/controller/action/esto es un vhost.
>>
>>>> 2011/3/3 socendani<socend...@gmail.com>
>>
>>>> Hola a todos.
>>
>>>>> Quisiera proponer al equipo alguna idea sobre lo que me es complejo de
>>>>> kumbia
>>
>>>>> No consigo una sinton�a ideal en el sistema kumbiaphp para el cambio
>>>>> de entornos.
>>>>> Quiz�s no lo hago correctamente, encantado de que me gui�is un pel�n..
>>
>>>>> La situaci�n habitual es que programamos en local y subimos las
>>>>> p�ginas por ftp al servidor de test y al servidor de producci�n. Lo
>>>>> que implica que no puede haber diferencias entre los ficheros (ni
>>>>> siquiera los ini) porque ya me ha pasado que he sobreescrito el
>>>>> config.ini y ... petada de conexi�n..
>>
>>>>> En la wiki oficial hay esto:
>>>>> http://wiki.kumbiaphp.com/Pasar_a_produccion
>>
>>>>> pero no lo veo pr�ctico, porque los ficheros se suben varias veces (y
>>>>> ahora me tengo que estar acordando de oculatr los.ini) y adem�s, solo
>>>>> concibe producci�n: on/off.
>>
>>>>> Mi ideal ser�a:
>>>>> * databases.ini => [etiquetas_necesarias] por ejemplo: [development].
>>>>> [testing].[production], etc...
>>>>> * config.ini =>[etiquetas_necesarias] por ejemplo: [development].
>>>>> [testing].[production], etc...
>>>>> * En el public/index.php poder definir el estado del entorno
>>>>> din�micamente por switch case del HTTP_SERVER, que permita definir
>>>>> las urls de dev, test, production o lo que sea..
>>>>> y al ejecutar el kumbia/bootstrap escoga los par�metros de la label
>>>>> definida anteriormente de forma din�mica..
>>>>> * la activaci�n del cacheo y el log podr�a activarse con variables
>>>>> propias en el config.ini en vez del concepto: production = Off / On
>>
>>>>> Bueno, solo es una idea...
>>
>>>>> Para solventarlo, modificar� el bootstrap, para que me permita tener
>>>>> config.inis diferentes o algo por el estilo.. pero ser�a ideal que
>>>>> fuera m�s parametrizable y no tocar el core.
>>
>>>>> Mis felicitaciones al trabajo de kumbiaphp.. el arranque de un site
>>>>> con kumbia es realmente r�pido y c�modo, aunque la �ltima descarga de
>>>>> *bzr me fall� algo con el PDO y tuve que tirar de la beta2 de
>>>>> kumbia.svn.sourceforge.net pero buen... que genial todo!
>>
>>>>> dani
>>
>>>>> --
>>>>> Viva KumbiaPHP Framework!
>>>>> http://www.kumbiaphp.com/
>>>>> Ha recibido este mensaje porque est� suscrito a Grupo "KumbiaPHP
>>>>> Framework" de Grupos de Google.
>>>>> Para obtener m�s opciones, visita este grupo en
Deivinson Tejeda
Deivinson Tejeda
socendani
Lo del static_path es justamente lo que planteas en el post anterior,
un static.dominio.com, configurado específicamente .. al estilo de
load de google (por ejemplo), sólo activable en ciertos entornos (test/
prod, pro ejemplo)... pero bueno, no es relevante ahora.
lo del vhost lo volveré a mirar, ok.. tengo que pensar en los
externos, en los maquetadores, etc.. en que ahora mismo ni tengo
equipo propio y voy saltando (y con windows, instalando xampp y
netbeans y a correr..), pero es algo particular y espero temporal del
lugar donde acabo de aterrizar.. está todo patas arriba, muy
desorganizado y con más de 30 proyectos desordenados que van
apareciendo .... para entregar y subir ...ayer..
He estado tan liado ayer gestionando bugs de proyectos creados
externamente que aún no he tenido tiempo de pensar en los .ini... a
voz de pronto mi idea va a ser crear config_dev.ini, config_prod.ini,
config_test.ini ... y modificar el core para que lea uno u
otro ...mientras no encuentre otra idea que no sea modificar en el
servidor config.ini y que venga un maquetador por ftp y me chafe el
config.ini del servidor de desarrollo sobre el de produccion porque en
el filezilla no ocultó los *.ini.. (esto ya ha pasado..)
Deivinson, ahora tengo que comenzar 2 proyectos diferentes con un poco
de todo.. timming 6 días cada uno.. he de volar..
me bajé la revisión 921 de : http://kumbia.svn.sourceforge.net/viewvc/kumbia/branches/1.0/
(entiendo que es la beta2)
y también me bajé de bazzar: https://code.launchpad.net/~desarrollokumbia/kumbia/spirit
(entiendo que es la beta2.1 en desarrollo)
bueno.. a ver si le dedico unos minutos más y me aclaro...
gracias por todo chicos!
Me reitero, personalmente, excepto el detallito de los ini (que
empiezo a ver que es exclusivamente manía mía).. kumbiaphp.. un 10.
Dani :-)
(@devinson... mis felicitaciones papi)
On 3 Març, 16:19, Deivinson Tejeda <deivinsontej...@kumbiaphp.com>
wrote:
> tedioso, llevo mucho tiempo trabajandolo asi y creenme que va muy bien y
> como te comente mas arriba es una forma de no tener problemas con rutas
> relativas al root de tu dominio... lo ideal es que todo este en el root del
> dominio.
>
>
>
> > Demonio, puedes tener un subdominio para contenido estatico que es lo mas
> > lógico y orientado hacia las buenas prácticas de desarrollo, supone que la
> > velocidad de tu app mejora, porque solo podemos hacer 2 request
> > simultaneamente sobre el mismo dominio ;)
>
> > Para ese caso de tu contenido estatico es mas facil aún :) con crear el
> > dominio static.dominio.com como siempre tiene un DocumentRoot pues el
> > document root sera el dir public/ esto solo para contenido static imagina
> > que todas tus app sean comun en esto va de maravillas...
>
> > Ahora para tu app solo necesitas el file public/index.php nomas ;-) esto
> > porque KumbiaPHP tiene un Front Controller[1] es decir imagina que tienes el
> > dominio.com y el documentroot de este es public_html/index.php mas nada...
> > porque lo correcto es que no tenga en el dir public del dominio ni la app/
> > ni el core/
>
> > Me vas siguiendo la idea? entiendo tu caso perfectamente, tuve la
> > oportunidad de tener varios proyectos bajo esas características, no se que
> > tanto tienes avanzado pero en la versión actual del SVN (actualizada ayer)
> > tiene un bootstrap por app que te alivia el trabajo de ir al core,
> > simplemente tocas ese para que te de el juego que necesitas :-)
>
> > [1]
>
> > 2011/3/3 socendani <socend...@gmail.com>
> >> > > se hace el calculo).
>
> >> > > Recordar que KumbiaPHP hace esto para que la instalación sea mas
> >> cómoda.
>
> >> > > El log y cacheo son cosas distintas, asi que si creas log
> >> > > ellos seguirán generándose al igual que si haces cache. La única
> >> diferencia
> >> > > es que estando en modo production=off KumbiaPHP no generara la cache
> >> porque
> >> > > asumes que estas desarrollando y no veras los cambios.
>
> >> > > En el futuro release, ya hay disponible un bootstrap para la app, en
> >> donde
> >> > > se podrá parametrizar muchas mas cosas que como desarrollador
> >> queramos.
>
> >> > > ¡Éxitos!
>
> >> > > 2011/3/3 Deivinson Tejeda <deivinsontej...@kumbiaphp.com>
>
> >> > > La idea es tener un entorno local tan parecido como el de
> >> > >> production quizás la diferencia mas marcado es habilitar todos los
> >> errores y
> >> > >> no tener un ambiente para tener alto rendimiento (cache, apc, etc..)
>
> >> > >> Incluso recomiendo tener vhost asi simulas como si tu aplicación
> >> estuviese
> >> > >> funcionando en tu dominio y no en
> >> > >>http://localhost/xxxx/controller/action/mejorseria tenerlo en local
Deivinson Tejeda
Para seguir con este hilo, ya que bajaste la versión del svn y launchpad podrás ver en [app]/libs/boostrap.php
Ahi puedes jugar mucho digamos que puedes entonar aun mas tu aplicación y hacer lo que deseas.
Éxitos!