Continuous DeliveryUn caso de estudio

#nerdearlaBuenos Aires, 2015

aka

Technical Learningsof Continuous

Delivery for MakeBenefit Glorious

Nation of Sysadmins

whoamioficio: sysadminIRC: osvaldo at freenode #sysarmy

it all started with a ...

Codigo:Trunk. Codigo en desarrolloBranch. 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 releaseQA. Release en produciónPROD.

como era el desarrollo

codigo + deploy steps

crear carpetasejecutar sqldeployar configuracionrollback steps

Documentation:JIRA Issues - code commits with jira_id on subject

tareas:

como era el deployment

Lunes: Code freezeMiércoles: Deploy a producción

Cada 15 dias

08:00 Arrancaba el deploy...terminaba cuando terminaba

como eran los releases

ReleasesProblemas?

FeriadosRollbacksTiempo de implementación paranuevas funcionalidad

empecemos por elprincipio

follow the money

(en nuestro caso:)

follow the code

flujo de codigo

Developers -> commit code in SVN

Release Team -> Push/Tag Code -> Deploy Code

Coordinación via: IRC

Problemas

Dependencia en el Release TeamProceso manual

flujo de codigo

¿Qué hacer?

Departamento de InfrastructuraRelease Team

Continuous DeliveryContinuous IntegrationContinuous Deployment

Continuous DeliveryEstas 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 porencima de trabajar en nuevas funcionalides.Cualquiera puede obtener feedback instántaneo yautomatizado de la disponibilidad para salir aproducción de sus sistemas siempre que alguienhaga un cambio sobre ellos.Puedes deployar cualquier versión del software acualquier ambiente en cualquier momento con soloapretar un botón.

Continuous DeliveryPara lograr continuous delivery usted necesita:

una relación de trabajo muy cercana y colaborativaentre todos los involucrados en el deployment(también conocido como "cultura DevOps".la mas completa automatización de todos loselementos que componen el proceso de delivery,usualmente conocido como DeploymentPipeline.

Continuous Delivery se confunde a menudocon Continuous Deployment. Continuous Deployment significa que cada cambioentra en el pipeline y automáticamente llega aproducción, resultando muchos deployments aproducción a diario.Continuous Delivery solo significa que tienes lacapacidad para hacer deploys frecuentes pero puedeselegir no hacerlos.

se refiere por lo general a lacapacidad de integrar, buildear y testear el código dentrode un ambiente de desarrollo.

Continuous Integration

Unit TestingAutomated Acceptance TestsUser Acceptance Tests

¿Por dondeempezamos?

show me the code

aka

Source Code Versioning

GitVentajas

Branchesmejor interface web (github/gitlab)repositorios distribuidos (oficinas distribuidas)interface svn (facilita la migración)

problema adicional con SVNoficinas distribuidas

geograficamentesolucion:

comenzar migración a gitseparar componentesseparar configuración del códigoreescribir deployment scripts. separación delcódigo y los datos de configuración

objetivos

Etapa 1

un grupo de proyectos empezo a utilizar git/github.se logró separar en componentes funcionalidad de laaplicación (frontend mostly).se paso la configuración a repositorios git (git-crypt).se armó el pipeline de un componente desde el commitde codigo comenzando por testing hasta stagingincluyendo unit testing, smoke tests y automatedacceptance tests.nuevo set de scripts de deployments (bash).

logros

primer pipeline: la prueba de concepto fue un exito

Etapa 1

disparar el deploy del componente automaticamente alcomitear nuevo codigo (github webhooks + jenkins git plugin)empaquetar los componentes

deployar paquetes -no source code- en ambientesartifactory

deployar paquetes automáticamente en ambientes dedesarrollo: testing y stagingun solo set de scripts (bash) de deploy para todos losambientes. configuracion de ambientes mediante includes

objetivos

Etapa 2

logrosEtapa 2

automatizar deploy de servidores de CI (aka jenkins)infrastructura como códigoutilizar paquetes nativosutilizar ansible en vez de bashdesarrolladores con el boton para deployar enproducción

objetivos

Etapa 3

deploys directo a producciónconfig flags: paquetes con la configuración defuncionalidades de la aplicacióntres 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

Smoke testsUAT (gnu parallel para acelerar casperjs)Canary deploymentsBlue/Green deploymentsfocused A/B testing (optimizely.com)

facilitando los deploys

LeccionesConvention over configurationtreat servers like cattle not petsautomate everythinginfrastructure as codeuse dev/qa environmentshave meaninful dev/qa environmentsempower developers - with great power came greatresponsabilities blameless postmortems

Herramientaslogging

splunkelk (logstash+kibana)

metricas

graphitenewrelic

repositories

artifactoryaptly

monitoreo

nagiospagerduty

source code versioning

githubautomatizacion

ansible / bashserver CI

jenkins

ChatopsIRChipchatslacklets-chat

Bots

hubotIntegracion

jenkinsgitlab/githubbash/curl

# 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

web panel

ansiblefpmaptly

arquitectura modular

inputoutput

multi-ambiente

paquetes nativos

infrastructure as code: xcdc

Tipsvagrant (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)

Document everythingstatic blog tools

jekylloctopresshugopelycan

wysiwygghost

static sitesmkdocsgitbook

apidocjs.com

use markdowngists

Gracias!