continuous delivery un caso de estudio
TRANSCRIPT
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 = "repos2mng" server = "onlinemainnms" script="ssh "+server+" /usr/local/acme/bin/checkartifactsservers.sh" else #server = "testingrepos2" server = "stagingnms" env = "stage" script="ssh "+server+" /usr/local/acme/bin/checkartifactsservers.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!