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

[Ariel Gerardo Ríos]

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.

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 <http://www.linkedin.com/pub/ariel-gerardo-rios/33/158/227> | *blog
<http://www.ariel17.com.ar>*
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <http://listas.python.org.ar/pipermail/pyar/attachments/20140813/8f50ac52/attachment.html>