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

[Andres Riancho]

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