Embed Size (px)
Citation preview
Cuidado com o vãoSeis etapas para ligar operações e desenvolvimento de software com o gerenciamento de versãoPor Greg Hughes, CEO, Serena Software (agora, Micro Focus®)
White Paper
Índice página
Quando o gerenciamento de versão dá errado . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Porque o gerenciamento de versão é tão difícil? . . . . . . . . . . . . . . . . . . . . . . . . . . 2
Gerenciamento de alterações: Necessário, mas insuficiente . . . . . . . . . . . . . . . . 3
DevOps: Cuidado com os puristas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Entrega contínua: Metade da solução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Melhores práticas de gerenciamento de versão: Seis etapas para o sucesso . . . 6
Quando o gerenciamento de versão dá certo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Cuidado com o vão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Agradecimentos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Bibliografia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1www.microfocus.com
Em todo lugar, o desenvolvimento de software é o motor da inovação . A inovação de
software destrói modelos de negócios existentes, possibilitando a criação de produtos
e serviços mais inteligentes e direcionados . Para assegurar que serão as rompedoras de
paradigmas e não o próprio paradigma rompido, empresas investem capital significativo
no gerenciamento do ciclo de vida do desenvolvimento de software (SDLC) .
No entanto, um vão no SDLC é está reduzindo a velocidade de inovação de novos aplicativos
e causando a falha de sistemas críticos para os negócios . Este vão está situado entre os
setores de desenvolvimento e operações: a tradicional “terra de ninguém” em termos de
responsabilidade, equipamento e foco . Preencher este vão precisa ser uma das maiores
prioridades para as empresas modernas .
Para grandes empresas altamente reguladas (HRLE) em setores como serviços financeiros,
seguros, saúde, aeroespacial, defesa e governamental, lidar com este vão é imprescindível .
Uma falha de versão de software pode destruir marcas, reputações, status regulatório e
outros ativos que podem exigir anos para reconstruir .
Enquanto muitas empresas têm iniciativas em andamento para aplicação de DevOps, ITIL
(Information Technology Infrastructure Library - Biblioteca de Infra-Estrutura de TI) ou CD
(Continuous Delivery - Fornecimento contínuo) para preencher o vão entre desenvolvimento
e operações, essas abordagens são insuficientes no HRLE apesar das promessas de seus
praticantes .
Então, como grandes empresas altamente reguladas lidam com o vão entre desenvolvimento
e operações? A disciplina emergente do gerenciamento de versão é a resposta .
Quando o gerenciamento de versão dá errado
Às 11:32 de quarta-feira, 8 de julho de 2015, o funcionamento da Bolsa de Valores Nova
York (NYSE) foi interrompido . Inicialmente, muitos temiam que o fechamento tivesse sido
causado por um ataque cibernético em infraestruturas críticas nos Estados Unidos e até
mesmo o Presidente Obama foi informado sobre o problema* .
A origem do fechamento da NYSE, entretanto, não foi mal-intencionado e poderia ter sido
evitada . O fato ocorreu por causa da falha de uma nova versão de software . No dia seguinte,
conforme informado pelo Wall Street Journal, a NYSE “confirmou que a atualização do
“motor de correspondência” da bolsa levou a problemas de comunicação entre corretores
e a NYSE” (Hope, 2015). Na declaração da NYSE, a bolsa declarou que o “a configuração
adequada compatível com a nova versão não foi carregada nos gateways do cliente .”
Como grandes empresas altamente reguladas lidam com o vão entre desenvolvimento e operações?
__________
* Algumas horas atrás, a United Airlines solicitou aterrissagem de aviões por causa de uma falha não relacionada de um roteador, aumentando a ansiedade da situação.
Índice página
Quando o gerenciamento de versão dá errado . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Porque o gerenciamento de versão é tão difícil? . . . . . . . . . . . . . . . . . . . . . . . . . . 2
Gerenciamento de alterações: Necessário, mas insuficiente . . . . . . . . . . . . . . . . 3
DevOps: Cuidado com os puristas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Entrega contínua: Metade da solução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Melhores práticas de gerenciamento de versão: Seis etapas para o sucesso . . . 6
Quando o gerenciamento de versão dá certo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Cuidado com o vão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Agradecimentos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Bibliografia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2
White PaperCuidado com o vão
Quando um problema de gerenciamento de versão interrompe o funcionamento de uma das
instituições mais importantes para o funcionamento tranquilo da economia mundial, isso
claramente é um grande problema para qualquer empresa .
É raro passar uma semana sem uma notícia na mídia sobre uma falha empresarial devido a
uma falha de versão de software. No fim de semana de 15 a 16 agosto de 2015, cerca de 1.000
voos de comerciais na costa leste dos EUA sofreram cancelamento ou atraso devido a uma
falha de atualização de software. Viajantes em férias de verão ficaram presos em aeroportos
por horas esperando por seus respectivos voos . Um defeito na nova funcionalidade
distribuída para o sistema ERAM (En Route Automation Modernization - Modernização
de automação na rota) causou o problema . O ERAM havia substituído recentemente um
sistema de aproximadamente 40 anos de idade usado pelos centros de controle de tráfego
aéreo da FAA (Brown, 2015) .
Porque o gerenciamento de versão é tão difícil?
Grandes organizações de TI têm dois grupos de pessoas: o grupo de desenvolvedores e o de
operações . Essas tribos são separadas em muitos aspectos (localização física, conjunto de
habilidades, metodologias/práticas, experiência, temperamento, metas e objetivos) .
Quando ocorre algo errado com uma versão de software, começa a atribuição de culpa .
A equipe de operações diz:
“Nós não tínhamos ideia do que viria do desenvolvimento.”
O desenvolvimento diz:
“Funciona bem no meu computador!”
A responsabilidade pela liberação de novo software se divide entre dois campos separados
que veem as alterações de forma bem diferente e dependem de sistemas individuais para
fazer o trabalho . Reconciliar essas diferenças só é possível com o gerenciamento de versão .
A responsabilidade pela liberação de novos softwares se divide entre dois campos separados que veem as alterações de forma bem diferente e dependem de sistemas individuais para fazer o trabalho. Reconciliar essas diferenças só é possível com o gerenciamento de versão.
3www.microfocus.com
Gerenciamento de alterações: Necessário, mas insuficiente
Muitas empresas de grande porte altamente reguladas (HRLEs) adotaram a estrutura
de processo ITIL (Information Technology Infrastructure Library - Biblioteca de Infra-
Estrutura de TI) e implementaram aplicativos de gerenciamento de serviços de TI
que incluem módulos de gerenciamento de alterações para dar suporte aos processos
operacionais . Apesar de muitas vezes ouvirmos os termos “gerenciamento de alterações” e
“gerenciamento de versão” serem usados alternadamente, eles representam duas disciplinas
distintas e importantes no SDLC . O gerenciamento de alterações é destinado a determinar
quais alterações serão aceitas, implementadas e implantadas . O gerenciamento de versão
é decide quais alterações devem ser inseridas, monitorando-as ao longo do ciclo de vida da
versão, proporcionando visibilidade a essas alterações e assegurando que elas sejam movidas
para produção de forma segura .
O gerenciamento de versão é responsável pela movimentação e implementação da
solicitação de alteração ao longo do ciclo de vida do desenvolvimento do aplicativo . Em
geral, ele começa quando a versão recebe um nome, por exemplo, 4th-Quarter Release . Isso
é quando o conteúdo – primeiro as solicitações de alterações e depois os requisitos, código,
scripts de teste, resultados de testes e aprovações – é enviado para liberação e é enviado para
desenvolvimento, teste, teste de integração de sistemas (SIT), teste de aceitação do usuário
(UAT), pré-produção ou propagação em fases, depois para a produção .
A prática de gerenciamento de versão assegura que o empreendimento segue o processo
de liberação durante todo o ciclo de vida de desenvolvimento de sistemas (SDLC) (metas
atingidas, aprovações obtidas) e que os artefatos certos sejam movidos de etapa a etapa de
forma completa, segura e ágil .
Sem um forte gerenciamento de versão, as HRLEs geralmente acham o gerenciamento e
a comunicação de alterações extremamente complexo, especialmente devido ao grande
volume de alterações sendo movidas para produção toda semana . O gerenciamento de
versão reduz drasticamente a complexidade agrupando um acervo de alterações menores
juntas em um conjunto .
O gerenciamento de versão é responsável pela movimentação e implementação da solicitação de alteração ao longo do ciclo de vida do desenvolvimento do aplicativo.
4
White PaperCuidado com o vão
DevOps puro prega a mistura de funções e o compartilhamento de responsabilidades entre as equipes de desenvolvimento e operações – em alguns casos, a criação de unidades “DevOps” treinadas nas respectivas disciplinas.
DevOps: Cuidado com os puristas
Algumas organizações estão experimentando com DevOps para aprimorar a colaboração e
coordenação entre desenvolvimento e operações, mas DevOps não é a panaceia para HRLEs .
DevOps puro prega a mistura de funções e o compartilhamento de responsabilidades
entre as equipes de desenvolvimento e operações – em alguns casos, a criação de unidades
“DevOps” treinadas nas respectivas disciplinas . Entretanto, em uma HRLE há razões
importantes para manter a separação entre desenvolvimento, QA e operações . Por exemplo:
Conformidade com normas exige a separação de funções entre desenvolvimento e operações. A separação de funções é um dos controles internos mais eficazes e algumas HRLEs adulteram a prática. Dar aos desenvolvedores o acesso a à produção é inviável em uma HRLE (Bird, 2014).
Os benefícios do escalonamento podem ser obtidos consolidando os data centers e nuvens particulares em uma só equipe compartilhada de operações com desenvolvimento alinhada a unidades de negócios específicas.
Divisão de trabalho pode resultar em melhor eficiência. Especialistas em áreas técnicas ou operacionais (por ex., desenvolvimento enxuto, segurança de rede, DBA Oracle) podem ser mais produtivos aproveitando suas habilidades concentradas em vez de se tornarem “generalistas” valorizados por DevOps. Na escala de uma HRLE, é muito difícil depender de indivíduos tão raros. Deixe o desenvolvedor desenvolver!
Alguns dizem que DevOps “não funciona” em grandes empresas, mas a questão não é tão
simples . (Shannon-Solomon, 2014) . Muitas ideias criadas no movimento DevOps são válidas
e úteis, mas HRLEs devem tomar cuidado especial para separar o que é aplicável do que é
prejudicial, custoso ou inviável . O conceito de um “Livro de receitas de DevOps,” em que
HRLEs escolhem quais ideias específicas aplicar em seus ambientes, é intrigante (Kim,
2015) .
Entrega contínua: Metade da solução
A entrega contínua é outra prática popular em muitas organizações (Humble & Farley,
2011) . Uma base fundamental da entrega contínua é um “pipeline em CD” que automatiza
o progresso do código desenvolvido pelo SDLC para produção — criação, teste, propagação
em fases e promoção . As empresas criam um pipeline em CD usando ferramentas para
automatizar o gerenciamento de configurações, versões e configurações.
5www.microfocus.com
Um pipeline em CD é muito útil no aprimoramento do gerenciamento de versão .
Automatizar etapas no SDLC elimina o trabalho manual, reduz erros e aprimora a
repetibilidade . Pipelines em CD são muito bem-sucedidos em empresas criadas ao redor
de um único aplicativo e uma infraestrutura moderna e simples, como Netflix, Etsy e Box.
Entretanto, grandes empresas altamente reguladas são muito mais complicadas . Elas
podem ter dúzias a centenas de aplicativos cruzados com interdependências complexas
e executando em uma variedade de ambientes antigos e novos (incluindo sistemas
mainframe) . Por exemplo, Generali France, a segunda maior empresa de seguros da França,
gerencia um total de 470 aplicativos com uma média mensal de 200 implantações de
produção para o mainframe e 190 para ambientes distribuídos .
Essa complexidade torna crítica a adoção de entrega contínua para HRLEs para
complementar as iniciativas de pipeline em CD com uma solução de gerenciamento de
processo para controlar as aprovações, governança, ambientes, e fluxos de trabalho humanos
por trás do gerenciamento de versão . Controles de processo asseguram que ambientes
de propagação mais recentes (como UAT, pré-produção e propagação em fases) sejam
gerenciados de forma eficiente, correta e responsável.
Por razões de conformidade com normas e visibilidade interna, as HLREs precisam
ser capazes de rastrear uma alteração na produção até os requisitos, defeitos ou
aprimoramentos que desencadearam essa alteração juntamente com as atualizações de
código-fonte correspondentes . Os pipelines em CD concentram-se nos artefatos principais
(código, configuração), de modo que uma solução completa precisa unir esses artefatos com
o resto do conteúdo da versão (por ex ., requisitos, aprimoramentos, defeitos) .
Devido aos custos gerados por falhas, as HRLEs precisam manter uma “contramedida” para
um rollback, caso ocorra uma falha grave em uma versão . Puristas de CD geralmente exigem
a abordagem de “reparos posteriores”, que não é prática quando o tempo de espera pode
resultar em prejuízos ao empreendimento .
Por razões de conformidade com normas e visibilidade interna, as HLREs precisam ser capazes de rastrear uma alteração na produção até os requisitos, defeitos ou aprimoramentos que desencadearam essa alteração juntamente com as atualizações de código-fonte correspondentes.
6
White PaperCuidado com o vão
Melhores práticas de gerenciamento de versão: Seis etapas para o sucesso
Se as iniciativas de ITIL, DevOps ou entrega contínua não forem suficientes, como as HRLEs
devem lidar com o vão entre o desenvolvimento e operações?
As seis etapas a seguir ajudarão as HRLEs a dominar as melhores práticas de gerenciamento
de versão e assegurar o sucesso na entrega de aplicativos . Comparando as práticas atuais às
descritos abaixo, a maioria das organizações perceberá que há mais a fazer para “lidar com o
vão” entre o desenvolvimento e operações .
Etapa 1: Nomear um líderA primeira etapa é nomear um líder . Qualquer potencial líder deve ser visto como negociante
honesto e confiável que dará ouvidos aos problemas e necessidades de todos os grupos.
O que o empreendimento precisa é de equilíbrio entre as metas de desenvolvimento e
operações, ou mover-se rapidamente sem quebrar nada (Hughes, 2015) .
Se a versão for de responsabilidade do lado de desenvolvimento, a tendência ser otimista
sobre as alterações no software e colocar em produção rapidamente, mas a qualidade
e a estabilidade da produção podem sofrer por consequência disso . Se a versão for de
responsabilidade do lado de operações, a tendência é ser mais pessimista e atrasar a
velocidade da entrega para proporcionar mais tempo de teste, mas a qualidade da produção
é mais alta . É por isso que o gerenciamento de versão em grandes empresas altamente
reguladas muitas vezes é responsabilidade da organização de controle de qualidade (CQ),
situada “entre” desenvolvimento e operações .
Onde quer que seja a sede do líder, ele ou ela deve ter uma compreensão do SDLC do
empreendimento, dos aspectos técnicos e de processo do gerenciamento de versão e uma
boa compreensão da tolerância da empresa em relação a riscos (alcançar o equilíbrio correto
entre velocidade e cautela) .
E, mais importante, o líder precisa de apoio dos executivos sênior e empoderamento para
impulsionar mudanças nas práticas de desenvolvimento, QA e operações .
A primeira etapa é nomear um líder. Qualquer potencial líder deve ser visto como negociante honesto e confiável que dará ouvidos aos problemas e necessidades de todos os grupos.
7www.microfocus.com
Métricas claras e mensuráveis ajudam a unir as equipes de desenvolvimento e operações por um objetivo comum.
Etapa 2: Definir os objetivos e métricasEm segundo lugar, defina os objetivos e métricas para o processo de gerenciamento de
versão. Comece pela meta final e depois trabalhe para ver como alcançá-la. Defina como
medir o progresso ao longo do caminho .
Métricas claras e mensuráveis ajudam a unir as equipes de desenvolvimento e operações
por um objetivo comum . Os executivos vão apreciar a nova transparência no ciclo de vida do
desenvolvimento do software .
Existem muitas formas possíveis de medir o sucesso de uma versão e ter uma conversa
com os envolvidos sobre possíveis métricas ajudará a desenvolver vocabulário e
comprometimento comuns entre eles . Por exemplo, os objetivos a seguir são válidos:
Aumentar o throughput da versão (ou alteração)
Reduzir versões não programadas
Melhorar a adesão ao escopo
Reduzir o tempo de espera (o tempo do commit do código à produção)
Aumentar a qualidade da entrega final
Aprimorar a percepção de datas, programação e metas de lançamento
Esta etapa é concluída quando o líder alcança o consenso sobre relatórios e painéis
de controle usados para o processo de gerenciamento de versão. Por fim, o objetivo é
desenvolver geração de relatórios e dados em tempo real sobre as métricas importantes
que medem a integridade do processo de gerenciamento de versão . As métricas têm duas
finalidades: proporcionar melhor visibilidade e compreensão do processo e possibilitar
programas contínuos de aprimoramento .
Etapa 3: Mapear um processo disciplinadoA próxima etapa é para mapear um processo de gerenciamento de versão disciplinado e
colaborativo com fluxos, portões, aprovações e fluxo de informações definidos. Geralmente,
há vários caminhos ao longo do processo de liberação – por exemplo, um rápido para uma
pequena mudança emergencial e um mais lento para versões maiores . Diferentes unidades
de negócios em toda a empresa geralmente também exigem suas adaptações específicas.
8
White PaperCuidado com o vão
Dependendo do tamanho da versão, muitas especialidades funcionais na HRLE (por ex .,
jurídico, conformidade, segurança) e executivos de negócios exigirão aprovações . Entretanto,
é importante pensar com cuidado sobre quem realmente precisa integrar o processo de
aprovação, pois mais aprovadores podem tornar o processo mais lento sem necessidade,
confundir a prestação de contas e reduzir a responsabilidade . As empresas têm percebido
que eliminar etapas de aprovação desnecessárias pode aprimorar a qualidade e a frequência
de versões, concentrando a prestação de contas em menos pessoas .
Há muitas metodologias conceituais possíveis para um processo de gerenciamento de
versão, incluindo o modelo de maturidade em capacitação (CMM), transição de serviço ITIL
e entrega contínua (cada uma com seus pontos fortes e fracos) . Normalmente, as HRLEs
devem suportar vários tipos de processos devido à variação de níveis de maturidade em toda
a empresa . Para reduzir atividades desnecessárias, práticas de gerenciamento enxuto são
aplicadas com frequência .
As empresas devem planejar gastar seis a oito semanas de esforços nesta etapa . O trabalho
de compreensão do processo existente e desenvolvimento de novos processos melhores é
complicado e leva tempo .
Etapa 4: Controlar o conteúdoA etapa quatro é tomar o controle do conteúdo. Isso significa desenvolver uma estratégia
para assegurar que todos os artefatos do aplicativo, não apenas o código-fonte, estejam
no controle de versão e que a automação seja usada na maior parte possível do processo
de liberação do aplicativo . Inconsistência entre ambientes – desenvolvimento, teste de
componentes, teste de integração de sistemas, UAT, pré-produção e produção – devido a
ativos não controlados pode causar inconvenientes desnecessários . Pior ainda, ela pode
resultar em uma falha nos estágios finais da implantação.
As HRLEs devem criar um sistema de gerenciamento único com código-fonte mais
robusto para assegurar que seus ativos de software estarão seguros e controlados . Muitas
empresas permitem a proliferação de repositórios de código-fonte, uma situação piorada
se for baseada em código-fonte aberto como GIT e Subversion que são concebidos por
desenvolvedores para desenvolvedores, sem a segurança e conformidade exigida pela HRLE .
As HRLEs devem criar um sistema de gerenciamento único com código-fonte mais robusto para assegurar que seus ativos de software estarão seguros e controlados.
9www.microfocus.com
Etapa 5: Criar a infraestrutura de suporteQuando a empresa faz um progresso significativo nas etapas anteriores, a atividade de
selecionar as ferramentas para suporte do gerenciamento de versão pode ser iniciada .
Juntamente com a busca de critérios funcionais específicos, clientes potenciais também
devem fazer as seguintes perguntas para potenciais fornecedores:
Quanta experiência o fornecedor tem no suporte de necessidades especiais de grandes empresas altamente reguladas? O fornecedor tem um histórico de sucesso neste domínio complexo?
Ele fornece conformidade e segurança “out-of-the-box” com seus produtos ou é algo que precisa ser adicionado após o fato? Os produtos são escalados em equipes empresariais amplamente distribuídas vs. aplicação principalmente em grupos de trabalho menores?
Eles fornecem um conjunto integrado de produtos – ao longo do gerenciamento de código-fonte, controle de processos, automação de implementação de aplicativos – isso funcionará em conjunto sem grande personalização e manutenção? Eles funcionam com as outras ferramentas do SDLC? O fornecedor auxilia a empresa com mainframe e sistemas abertos?
Etapa 6: Definir a abordagem de governançaPor fim, a organização precisa criar uma abordagem de governança para gerenciamento de
versão . Um processo de gerenciamento de alterações em bom funcionamento, incluindo
conselhos de aprovação de alterações hierárquicos (CABs) é uma pré-condição para uma
boa governança de liberação . CABs de nível mais alto concentram-se em exceções, revisando
apenas as versões escaladas por um conselho de aprovação de alterações inferior .
Para funcionar, os CABs precisam de informações precisas, um processo controlado e uma
programação ativa de liberação . Então, é necessário colocar todo o resto em ordem antes que
os CABs possam surtir efeito . A maioria das HRLEs têm um aplicativo estabelecido usado
para dar suporte ao processo de gerenciamento de alterações para operações . Para permitir
o compartilhamento de informações em tempo real entre operações e liberação, a solução
de gerenciamento de versão e a ferramenta existente de gerenciamento de alterações devem
funcionar em integração .
Quando o gerenciamento de versão dá certo
Em empresas que dominam as seis etapas, o gerenciamento de versões é um processo bem
definido com os seguintes atributos:
Visível—o status completo das próximas versões do software está claro para todos.
Controlado—cada etapa do processo é executada e monitorada e as exceções são raras.
Em conformidade—um sistema de registro fornece todos os dados necessários para auditores e reguladores.
Para funcionar, os CABs precisam de informações precisas, um processo controlado e uma programação ativa de liberação.
10
White PaperCuidado com o vão
Livre de erros—atualizações do software executadas conforme necessário ou recuperadas imediatamente.
Alta velocidade—software lançado em horas e dias em vez de semanas e meses.
Eficiente—noites e finais de semana são raros e a automação é usada amplamente.
Seguro—o processo, propriedade intelectual e o aplicativo estão protegidos contra ameaças.
Por exemplo, a Generali France tinha três objetivos para sua iniciativa de gerenciamento
de versão: “Reduzir a complexidade da liberação, encurtar o ciclo de implantação para que
possa ser feito com poucos cliques e conformidade com novos regulamentos”, de acordo
com Cyril Thenon, gerente do centro de habilidades de desempenho e industrialização na
Generali .
Cuidado com o vão
O desenvolvimento de software precisa ser mais rápido em quase todas as empresas para
que continuem competitivas no mundo moderno . Entretanto, o vão entre as equipes de
desenvolvimento e operações geralmente impossibilita esse objetivo de acelerar o ciclo
de vida de desenvolvimento do software . Fazer a ponte os dois lados é uma prioridade,
especialmente para HRLEs .
Nas grandes empresas altamente reguladas, o vão entre as equipes de desenvolvimento e
operações não desaparece, apesar dos pronunciamentos otimistas de fanáticos por DevOps,
defensores de ITIL ou seguidores da entrega contínua . Portanto, a melhor abordagem é
tomar cuidado com o vão, dominando as práticas de gerenciamento de versão . Seguir as
seis etapas destacadas neste documento ajudará as empresas a começarem a trilhar esse
caminho com confiança.
Poucas empresas concluíram as seis etapas, o que significa que a maioria das organizações
ainda têm lugar para aprimoramento contínuo . Se a sua organização estiver apenas
começando a lidar com gerenciamento de versão, a primeira etapa é nomear um líder . Se
você tiver um líder, certifique-se de que você está criando consenso em relação aos objetivos
e métricas adequados . E assim por diante com cada uma das seis etapas . Onde quer que você
esteja na jornada para um melhor gerenciamento de versão, quase sempre há mais a fazer
para eliminar o vão!
O desenvolvimento de software precisa ser mais rápido em quase todas as empresas para que continuem competitivas no mundo moderno. Entretanto, o vão entre as equipes de desenvolvimento e operações geralmente impossibilita esse objetivo de acelerar o ciclo de vida de desenvolvimento do software.
11www.microfocus.com
Agradecimentos
Eu não poderia ter escrito este white paper sem a ajuda dos meus colegas na Serena (agora
Micro Focus) que são especialistas em SDLC e processos de gerenciamento de versão . Sou
especialmente grato a Tom Clement, Julian Fish, Steve LeWarne e Kevin Parker por suas
valiosas contribuições e comentários editoriais .
Bibliografia
Bird, J . (09 de janeiro de 2014) . Developers working in Production . Of course! Maybe,
sometimes . What, are you nuts? Retirado de Building Real Software: Developing and
Maintaining Secure and Reliable Software in the Real World: swreflections.blogspot.com
Brown, L . (17 de agosto de 2015) . Press Release—FAA Statement on Automation Problems
at Washington Center . Retirado do site da Administração Federal de Aviação dos EUA:
www.faa.gov
Hope, B . (10 de julho de 2015) . NYSE Says Wednesday Outage Caused by Software Update .
Wall Street Journal.
Hughes, G . (2015) . Move Fast Without Breaking Things . San Mateo, CA: Serena Software .
Humble, J ., & Farley, D . (2011) . Continuous Delivery: Reliable Software Releases through
Build, Test, and Deployment Automation . Pearson Education, Inc .
Kim, G. e. (2015). The DevOps Cookbook. A ser publicado em 2015—Versão prévia revisada
pelo autor .
Serena Software, Inc . (n .d .) . Generali France Achieves Greater Agility, Improved
Performance and Enhanced Security in its Release Process with Serena .
Shannon-Solomon, R . (Maio de 2014) . DevOps is Great for Startups, but for Enterprises It
Won’t Work—Yet . Wall Street Journal.
162-PB0079-001 | S | 04/17 | © 2017 Micro Focus. Todos os direitos reservados. Micro Focus e o logotipo Micro Focus, entre outros, são marcas registradas ou marcas comerciais registradas da Micro Focus ou de suas subsidiárias ou afiliadas no Reino Unido, Estados Unidos e outros países. Todas as outras marcas pertencem a seus respectivos proprietários.
www.microfocus.com
Micro FocusArgentina+54 11 5258 8899
Brasil+55 11 3627 0900
Colombia+57 1 622 2766
México+52 55 5284 2700
Venezuela+58 212 267 6568
Micro FocusSede da empresaReino Unido+44 (0) 1635 565200
www.microfocus.com
