Implementacion de Continuous Delivery

1. Continuous Delivery
Un caso de estudio
#nerdearla
Buenos Aires, 2015

2. aka

3. Technical Learnings
of Continuous
Delivery for Make
Benefit Glorious
Nation of Sysadmins

4. whoami
oficio: sysadmin
IRC: osvaldo at freenode #sysarmy

5. it all started with a ...

6. Codigo:
Trunk. Codigo en desarrollo
Branch. Versiones de Release
(3.10,3.11,3.12,..)
Tag. Fixes, bugs, etc. (3.10.1,3.10.2 .., 3.10.18,
3.11.0,..)
3 Ambientes:
DEV. Próximo release
QA. Release en produción
PROD.
como era el desarrollo

7. codigo + deploy steps
crear carpetas
ejecutar sql
deployar configuracion
rollback steps
Documentation:
JIRA Issues - code commits with jira_id on subject
tareas:
como era el deployment

8. Lunes: Code freeze
Miércoles: Deploy a producción
Cada 15 dias
08:00 Arrancaba el deploy
...
terminaba cuando terminaba
como eran los releases

9. Releases
Problemas?
Feriados
Rollbacks
Tiempo de implementación para
nuevas funcionalidad

10. empecemos por el
principio
follow the money
(en nuestro caso:)
follow the code

11. flujo de codigo
Developers -> commit code in SVN
Release Team -> Push/Tag Code -> Deploy Code
Coordinación via: IRC

12. Problemas
Dependencia en el Release Team
Proceso manual
flujo de codigo

13. ¿Qué hacer?

14. Departamento de Infrastructura
Release Team

15. Continuous Delivery
Continuous Integration
Continuous Deployment

16. Continuous Delivery
Estas haciendo continuous delivery cuando:
Tu código es deployable a lo largo de su ciclo de vida.
Tu equipo prioriza mantener el código deployable por
encima de trabajar en nuevas funcionalides.
Cualquiera puede obtener feedback instántaneo y
automatizado de la disponibilidad para salir a
producción de sus sistemas siempre que alguien
haga un cambio sobre ellos.
Puedes deployar cualquier versión del software a
cualquier ambiente en cualquier momento con solo
apretar un botón.

17. Continuous Delivery
Para lograr continuous delivery usted necesita:
una relación de trabajo muy cercana y colaborativa
entre todos los involucrados en el deployment
(también conocido como "cultura DevOps".
la mas completa automatización de todos los
elementos que componen el proceso de delivery,
usualmente conocido como DeploymentPipeline.

18. Continuous Delivery se confunde a menudo
con Continuous Deployment.
Continuous Deployment significa que cada cambio
entra en el pipeline y automáticamente llega a
producción, resultando muchos deployments a
producción a diario.
Continuous Delivery solo significa que tienes la
capacidad para hacer deploys frecuentes pero puedes
elegir no hacerlos.

19. se refiere por lo general a la
capacidad de integrar, buildear y testear el código dentro
de un ambiente de desarrollo.
Continuous Integration
Unit Testing
Automated Acceptance Tests
User Acceptance Tests

20. ¿Por donde
empezamos?

21. show me the code
aka
Source Code Versioning

22. Git
Ventajas
Branches
mejor interface web (github/gitlab)
repositorios distribuidos (oficinas distribuidas)
interface svn (facilita la migración)
problema adicional con SVN
oficinas distribuidas
geograficamente
solucion:

23. comenzar migración a git
separar componentes
separar configuración del código
reescribir deployment scripts. separación del
código y los datos de configuración
objetivos
Etapa 1

24. un grupo de proyectos empezo a utilizar git/github.
se logró separar en componentes funcionalidad de la
aplicación (frontend mostly).
se paso la configuración a repositorios git (git-crypt).
se armó el pipeline de un componente desde el commit
de codigo comenzando por testing hasta staging
incluyendo unit testing, smoke tests y automated
acceptance tests.
nuevo set de scripts de deployments (bash).
logros
primer pipeline: la prueba de concepto fue un exito
Etapa 1

25. disparar el deploy del componente automaticamente al
comitear nuevo codigo (github webhooks + jenkins git plugin)
empaquetar los componentes
deployar paquetes -no source code- en ambientes
artifactory
deployar paquetes automáticamente en ambientes de
desarrollo: testing y staging
un solo set de scripts (bash) de deploy para todos los
ambientes. configuracion de ambientes mediante includes
objetivos
Etapa 2

26. logrosEtapa 2

27. automatizar deploy de servidores de CI (aka jenkins)
infrastructura como código
utilizar paquetes nativos
utilizar ansible en vez de bash
desarrolladores con el boton para deployar en
producción
objetivos
Etapa 3

28. deploys directo a producción
config flags: paquetes con la configuración de
funcionalidades de la aplicación
tres paquetes por componente:
codigo (aplicación)
conf (configuración ambiente)
flags (funcionalidad aplicación)
pipeline de nuevo componente en un dia (hasta prod!)
logros
Etapa 3

29. Smoke tests
UAT (gnu parallel para acelerar casperjs)
Canary deployments
Blue/Green deployments
focused A/B testing (optimizely.com)
facilitando los deploys

30. Lecciones
Convention over configuration
treat servers like cattle not pets
automate everything
infrastructure as code
use dev/qa environments
have meaninful dev/qa environments
empower developers - with great power came great
responsabilities
blameless postmortems

31. Herramientas
logging
splunk
elk (logstash+kibana)
metricas
graphite
newrelic
repositories
artifactory
aptly
monitoreo
nagios
pagerduty
source code versioning
github
automatizacion
ansible / bash
server CI
jenkins

32. Chatops
IRC
hipchat
slack
lets-chat
Bots
hubot
Integracion
jenkins
gitlab/github
bash/curl

34. # check artifacts ­ Check artifacts versions in environment (available and deployed)
exec = require('child_process').exec;
module.exports = (robot)­>
robot.respond /check (.*)/i, (msg) ­>
env = msg.match[1]
switch env
when "prod"
#server = "repos2­mng"
server = "online­main­nms"
script="ssh "+server+" /usr/local/acme/bin/check­artifacts­servers.sh"
else
#server = "testing­repos2"
server = "staging­nms"
env = "stage"
script="ssh "+server+" /usr/local/acme/bin/check­artifacts­servers.sh"
console.log(script)
child = exec script, (error,stdout,stderr) ­>
msg.send "artifacts in "+env+"n" + stdout + "n" + stderr
CODE for hubot check prod

36. web panel

37. ansible
fpm
aptly
arquitectura modular
input
output
multi-ambiente
paquetes nativos
infrastructure as code: xcdc

38. Tips
vagrant (providers: lxc, vmware, azure)
vagrant plugins (hosts manager, package cache)
git push update (definir dos remotes, read-only via ssh,
read-write via https, bonus: git credentials cache)
use rest. /api/ (slim framework, flask)
jenkins
nodes (using different remote user)
backup scripts (backup jenkins´ configuration in git)

39. Document everything
static blog tools
jekyll
octopress
hugo
pelycan
wysiwyg
ghost
static sites
mkdocs
gitbook
apidocjs.com
use markdown
gists

40. Gracias!