O processo de liberação é um dos processos mais subestimados em uma empresa em crescimento. A maioria das startups escolhe entre duas versões de gerenciamento de lançamento: nenhuma ou totalmente automática. O último se encaixa principalmente em startups movidas a ruby / rails devido à disponibilidade de empresas de hospedagem baseadas em capistrano ou git. A variante “nenhum” significa, em nosso caso, implantação via checkouts svn no (s) servidor (es). Você poderia dizer que isso também é gerenciamento de liberação, mas se for honesto consigo mesmo …
As startups tendem a crescer e, portanto, você encontrará algum ponto no tempo em que precisará escalar os processos na inicialização. O processo de lançamento é um deles, conforme você obtém mais servidores, mais desenvolvedores e mais recursos por ciclo de desenvolvimento (eu tendo a não dizer sprint ou ciclo de lançamento para obter o ágil e classicamente gerenciado em um único barco). Além da complexidade do gerenciamento, a complexidade do software aumentará com cada recurso que você fizer. Frases como reversão, gerenciamento de dependência e multi-ambiente surgem em reuniões de tecnologia e o “gerenciamento por revista de bordo” surge com implantação contínua para reduzir drasticamente o tempo de lançamento no mercado (desculpe, nenhum link ou referência para o antipadrão – o artigo original parece ter sumido, mas eu acho que você pode imaginar o que isso significa? O CEO ou Desenvolvedor de Produto lê algo em uma revista durante uma viagem e entra no departamento de tecnologia para anunciar a alocação de recursos imediata no novo tópico quente (XYZ sem qualquer preparação ou mesmo sentido). Costumo chamar isso de DDD (desenvolvimento dirigido por sonhos), resultando em RDD (desenvolvimento dirigido pela raiva) no lado da tecnologia.
Quando você vem de uma agência da web (como eu) e começa a projetar um novo processo para essa empresa, você tende a confiar em um processo clássico de gerenciamento de lançamento. Começando pela maneira como as tarefas de recursos são atribuídas até o momento em que você constrói e implanta a parte do software no cluster de servidor. Foi provado que estou errado desde que declarei a tentativa de construir tal processo. O novo objetivo deve ser misturar os dois mundos, visando o máximo de flexibilidade dentro de um determinado nível de segurança de processo. Cortá-lo em pedaços menores para fazer as mudanças passo a passo torna mais fácil para os desenvolvedores e para o gerenciamento.
Este artigo foi publicado pela primeira vez em meu blog em http://www.xenji.com/blog/2012/12/30/release-process-from-startup-to-professional/index.html