[pyar] SDLC - Staging y Producción - requirements.txt

[Sebastián Seba]

El 13 de agosto de 2014, 9:11, Andres Riancho <andres.riancho en gmail.com>
escribió:

> Ariel,
>
> 2014-08-13 0:07 GMT-03:00 Ariel Gerardo Ríos <arielgerardorios en gmail.com>:
> > Hola Andrés:
> >
> >     Para todos los proyectos Python en los que participo hago una
> separación
> > de los requirementos en sus respectivos ambientes y dejo uno default que
> > apunta a producción: esta estrategia la saqué del libro "Two scoops of
> > Django" de Daniel Greenfield. Te quedaría algo así:
> >
> > /proyecto
> >     requirements.txt
> >     requirements/
> >         base.txt
> >         development.txt
> >         production.txt
> >         test.txt
> >
> > Lo que se hace es separar los requerimientos comunes de aquellos que
> están
> > asociados a cada ambiente. Quizás en development uses herramientas que no
> > usás en producción y viceversa. Te paso un ejemplo de los contenidos de
> los
> > archivos:
> >
> > requirements.txt
> >
> > # Default requirements
> > -r requirements/production.txt
> >
> > requirements/production.txt
> >
> > # Production requirements for project
> > -r base.txt
> > gunicorn==x.x
> >
> > requirements/development.txt
> >
> > # Development requirements for project
> > -r base.txt
> > django-debug-toolbar==y.y
> >
> > requirements/base.txt
> >
> > # Base (common) requirements for project
> > Django==1.7
> >
> >
> > Cuando vos querés armar el ambiente para development en tu herramienta de
> > integración continua, sólo es necesario indicarle que use el archivo de
> > requerimientos específico para ese ambiente:
> >
> > $ pip install -r requirements/development.txt
> >
> > Para armar el ambiente de producción podés usar el default o indicar
> > explicitamente cuál usar:
> >
> > $ pip install -r requirements.txt
> > $ pip install -r requirements/production.txt
> >
> > De esta manera, si mantenés todo "departamentalizado" no vas a tener
> > problemas a la hora de hacer merge desde branches de desarrollo hacia
> > producción.
>
> Elegante y además anda :) Justo lo que necesitaba, gracias!
>
> > Espero te sea útil.
> > Saludos!
> >
> >
> >
> > 2014-08-12 18:25 GMT-03:00 Andres Riancho <andres.riancho en gmail.com>:
> >>
> >> Lista,
> >>
> >>     Estoy intentando implementar continuous delivery para todos mis
> >> proyectos, y una de las cosas con las cuales me estoy topando es
> >> cuando un repositorio depende de otro y sus implicancias luego para el
> >> proceso de build y deploy. Me explico mejor,
> >>
> >>     Digamos que hay dos proyectos en dos repositorios distintos en
> >> Github: A y B.
> >>
> >>  * Ambos repositorios tienen dos branches: develop y master
> >>  * Develop se deploya a staging, master se deploya a produccion
> >>  * Cuando cambio algo en B, pasan los tests, etc. quiero que se
> >> buildee A con la nueva version de B
> >>  * Para no romper produccion quiero que si hago un cambio en
> >> B(develop) se buildee y deploye A(develop). El sistema de CI que uso
> >> permite hacer builds secuenciales, eso no seria un problema.
> >>
> >>     Ahora lo que me molesta es que el proyecto A tiene algo como esto
> >> en su requirements.txt hoy:
> >>
> >>         git+ssh://git@github.com/andresriancho/B.git@
> <hash>#egg=B==0.2.8
> >>
> >>     Notar que estoy apuntando directo a un <hash> / version. Entonces
> >> si quiero que A se buildee de manera automatica, al menos hoy, siempre
> >> va a tomar la misma version de B. Entonces pase a algo de este estilo:
> >>
> >>         git+ssh://git@github.com/andresriancho/B.git@staging#egg=B
> >>
> >>     Notar que ahora tengo "staging" como version. Esto funciono bien
> >> por un rato, hasta que hice un merge de develop a master y me quedo el
> >> requirements.txt de master tambien apuntando a B(staging).
> >>
> >>     Pense en varias maneras de solucionar esto, todas realizables y
> >> posiblemente en menor tiempo del que tarde en escribir este email ;)
> >> Pero ninguna es bullet-proof, linda, etc. Se toparon con este
> >> problema? Como lo solucionaron?
> >>
> >> Saludos,
> >> --
> >> Andrés Riancho
> >> Project Leader at w3af - http://w3af.org/
> >> Web Application Attack and Audit Framework
> >> Twitter: @w3af
> >> GPG: 0x93C344F3
> >> _______________________________________________
> >> pyar mailing list pyar en python.org.ar
> >> http://listas.python.org.ar/listinfo/pyar
> >>
> >> PyAr - Python Argentina - Sitio web: http://www.python.org.ar/
> >>
> >> La lista de PyAr esta Hosteada en USLA - Usuarios de Software Libre de
> >> Argentina - http://www.usla.org.ar
> >
> >
> >
> >
> > --
> > Ariel Gerardo Ríos
> > linkedin | blog
> >
> > _______________________________________________
> > pyar mailing list pyar en python.org.ar
> > http://listas.python.org.ar/listinfo/pyar
> >
> > PyAr - Python Argentina - Sitio web: http://www.python.org.ar/
> >
> > La lista de PyAr esta Hosteada en USLA - Usuarios de Software Libre de
> > Argentina - http://www.usla.org.ar
>
>
>
> --
> Andrés Riancho
> Project Leader at w3af - http://w3af.org/
> Web Application Attack and Audit Framework
> Twitter: @w3af
> GPG: 0x93C344F3
> _______________________________________________
> pyar mailing list pyar en python.org.ar
> http://listas.python.org.ar/listinfo/pyar
>
> PyAr - Python Argentina - Sitio web: http://www.python.org.ar/
>
> La lista de PyAr esta Hosteada en USLA - Usuarios de Software Libre de
> Argentina - http://www.usla.org.ar
>


+1 al esquema de requirements.txt propuesto en "Two Scoops of Django". Lo
vengo utilizando en la mayoría de mis proyectos con mucha felicidad. Anda
de 10 en Heroku también.

-- 
*Sebastián J. Seba*
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <http://listas.python.org.ar/pipermail/pyar/attachments/20140813/4d422e52/attachment-0001.html>