Add ci

[kyv]

Agregar configuración para integración continuo. Fixes #5

[martinszy]

Necesito algo de claridad sobre esto: 1) Por qué tenemos circle y travis? No convendría tener un sólo? 2) El circle tiene un paso de deploy, que por lo que veo crea un docker, pero ese docker no se envía a ningun servidor, cierto? 3) No deberíamos tener un servidor de desarrollo que automaticamente actualice ese docker y lo muestre?

[kyv]

1. Empezé con travis y luego cambié a circle porque en ciertos momentos travis tardaba hasta un dia para ejecutar un builid. Como ya estaba el configuración lo deje. La podemos quitar si asi si dicide.
2. si envia al el hub de imagenes de docker hub.docker.com. Pero no si arranca en nigun servidor de applicaciones.
3. Probablamente. Habrá que dicidir la mejor manera de orchestrarlo.

[martinszy]

1. Si, saquemos travis.
2. Ok.
3. Quizás en heroku? https://circleci.com/docs/2.0/deployment_integrations/#heroku

[kyv]

1. Pienso que seria mejor dejar la configuración en el codigo y picar la palomita en el sitio web de travis. De esta forma si la queremos en el futuro es solo prender el serivicio.
2. Si entiendo bien, ahora podemos empujar a heroku de la misma manera que empujamos a el registro de imagenes de docker. Si estoy correcto, esta manera seria preferible a los instrucciones documentados por circleCI. Falta terminar investigar la tema: https://devcenter.heroku.com/articles/container-registry-and-runtime

[kyv]

desde 95ecf965e el applicación en qqwext.heroku.com actualiza automaticamente desde este repo. El procedamiento es parecido con producción. al empujar un etiqute de format v0.0.0-staging la aplicación actualiza donde los ceros son numeros.

[martinszy]

Ok, dejemos travis. Por qué hay que hacer un tag para deployar? El espíritu de la integración continua no es que se hace en cada commit?

[kyv]

Quizás estas confundiendo integración continua con continous deployment? La cosa es que hay muchas maneras de hacer cada cosa.

https://en.wikipedia.org/wiki/Continuous_delivery#Relationship_to_continuous_deployment

De mi parte no veo la inconveniente en utilizar un tag como detonante. Implica la ubicación de intención del lado humano, lo cual no es siempre de malo. Nos permite un grado de flexibilidad donde podemos mandar la rama que queremos a staging en que queremos probar alguna cosa en la web.

[kyv]

Tienes alguna propuesta alterna?

[martinszy]

Para mi lo ideal es que cada vez que hacemos un push en la branch de dev se corran todos los tests, y si compila, que se deploye en el heroku de staging para que podamos verlo. Si querés limitar a que se pase a staging sólo cuando hacemos branch no me parece mal, pero si creo que los tests habriá que correrlos en cada push del branch de dev, así nos enteramos rápido cuando algo está roto... o mejor correr los tests en local?

[kyv]

No sé desde donde obtuviste la idea que no ejecutan las pruebas sobre la rama dev, pero hasta que entiendo cualcuier push a este repo ejecuta pruebas:

https://github.com/ProjectPODER/QuienEsQuien/commits/dev

[kyv]

De la otra punto, eso ejemplifica porque no queremos ligar fuertamente staging a una rama: es possible que dev este roto de vez en cuando. Tambien es possible que vamos a querer probar algun feature en staging.