Paul Bigger, co-fundador da empresa CircleCI falou sobre "maneiras de fazer deploy continuamente" na RubyConf 2013. A frequência com que os deploys acontecem restringem o significado de "contínuo" e influenciam diretamente o problema a resolver. A apresentação agrega informações sobre soluções colhidas diretamente da base de clientes da CircleCI, Facebook, IMVU Etsy, Heroku, e Google. O apresentador defende que cada companhia faz o deploy de maneira diferente, e que não existe solução única para deploy contínuo.
Biggar compartilhou detalhes sobre como as soluções de deploy têm processos envolvendo código, mudanças em bancos de dados, unidades de deploy, velocidade de implantação, testes e monitoramento. Também abordou as variáveis que afetam o desenvolvimento dessas soluções de deploy, incluindo velocidade de novas funcionalidades, complexidade do código, arquitetura de software, design de software, número de engenheiros e monitoração de estado.
Biggar explicou que a solução mais comum para gerenciar a transição de estados durante o deploy para produção, a "Corrida" (Race), foi publicar código que suporta novas e antigas funcionalidades. Isso requer engenheiros para programar a funcionalidade para que o novo código possa executar de forma segura lado a lado com o código antigo.
Bases de dados apresentam um desafio adicional em relação ao estado armazenado. No início pode parecer que atualizar toda a aplicação e permitir que gerencie ambas as versões da base de dados seria suficiente até finalmente mudar a versão da base de dados. Entretanto, em alguns casos a mudança da base de dados SQL causa tantos locks que a única opção razoável é criar uma nova tabela para cada versão e então migrar os dados. A aplicação teria que buscar as informações nas novas tabelas e, caso não as encontrar, realizar a busca nas tabelas antigas. O NoSQL tornou-se popular em parte por evitar cenários de locking.
A apresentação trata de outros aspectos do processo de deploy, incluindo a unidade de deploy, velocidade, validações através de testes e verificação através de monitoramento. Estes são requisitos não-funcionais do processo de deploy, mas o nível dessas capacidades determina até que grau o deploy é contínuo.