Indo tudo com o DevOps

Para muitas empresas, mudar para o desenvolvimento de software ágenero é como encontrar a nova tensão de grama - depois de meses de pesquisa - e depois plantar as novas sementes na antiga pageira. Seu gramado pode, finalmente, parecer um pouco melhor, mas levará mais tempo e os resultados não serão tão bons quanto se você tivesse removido as raízes das árvores escondidas, colocou em solo novo e repensou o sistema de irrigação. E eles esperaram expectativa pelos benefícios. Em teoria, a atribuição do Agile de um líder de negócios às equipes de desenvolvimento garante que as mudanças mais importantes de software sejam feitas primeiro e sua ênfase nas sprints de codificação curta garante que as alterações sejam implementadas rapidamente. O fato de a parte rápida nem sempre acontecer foi desanimadora. Tem alguns recém -chegados ágeis se perguntando se há algo que eles estão perdendo.

Many mainstream companies—in financial services, health care, manufacturing, consumer packaged goods, and other industries—have felt compelled to give agile software development a try. And they have waited expectantly for the benefits. In theory, agile’s assignment of a business leader to development teams ensures that the most important software changes get done first, and its emphasis on short coding sprints ensures that the changes are implemented quickly. The fact that the quick part doesn’t always happen has been discouraging. It has some agile newcomers wondering if there’s something they’re missing.

Em muitos casos, existe. O Agile faz um bom trabalho ao quebrar os silos no início do processo de desenvolvimento de software. Mas só pode alcançar muito por conta própria. Para se transformar em concorrentes digitalmente prontos, as empresas precisam repensar o inteiro Ciclo de vida de desenvolvimento de software. Eles precisam do ágil, mas também precisam de DevOps. (Consulte Anexo 1.) Com sua ênfase na execução de várias atividades em equipes paralelas e multifuncionais, o DevOps representa uma pausa do antigo modelo de “cachoeira”, no qual planejamento, escrita, teste e implantação de código foram etapas discretas gerenciadas por departamentos separados.

DevOps is an approach that integrates critical late-stage activities—like testing and deployment planning—into the code-writing part of software development. (See Exhibit 1.) With its emphasis on running multiple activities in parallel and on multifunctional teams, DevOps represents a break from the old “waterfall” model, in which planning, writing, testing, and deploying code were discrete steps managed by separate departments.

Enquanto muitas empresas de software usam alguma forma de desenvolvimento e lançamento contínuos de software que são a marca registrada do DevOps, a abordagem (que continua a evoluir e está começando a ser referida como serviços de DevOps 2.0 ou BizDops por alguns de seus praticantes mais avançados) é uma indústria mais nova e mais nova, a Tecnologia e a Internet. Algumas empresas tradicionais, principalmente em serviços financeiros, têm algumas peças do DevOps, como testes e mecanismos automatizados para o fornecimento de hardware rapidamente. (Ver " Mais magro, mais rápido e melhor com o DevOps , "Artigo do BCG, março de 2017.) Mas o escopo dessas práticas é limitado. As empresas não fizeram as mudanças gerais que lhes permitiriam capturar a gama completa de benefícios do DevOps.

Fazendo o DevOps funcionar

para Tire o máximo de DevOps , as empresas devem fazer alterações nos controles e governança, funções de organização de TI e modelos operacionais. 

Rethink Controles e Governança. Os controles podem ter feito sentido desde o início. Mas, à medida que o ritmo da mudança tecnológica acelerou, os controles perderam sua relevância. Agora eles são apenas obstáculos.   Most big companies’ approach to developing and releasing software reflects controls they put in place years ago to maintain quality and avoid costly mistakes. The controls may have made sense at the outset. But as the pace of technological change has accelerated, the controls have lost their relevance. Now they’re just obstacles.  

Por exemplo, um controle sobre o provisionamento de infraestrutura - um dos obstáculos que deve ser encimado antes que uma equipe de desenvolvimento possa começar seu trabalho - pode ter sido implementada nos dias anteriores à virtualização. Hoje, a virtualização disponibiliza a capacidade de computação e armazenamento com menos complexidade operacional do que antes e a um custo muito menor. Mas ainda vemos empresas recebendo um mês e mais de 50 e-mails apenas para provisionar hardware e reunir todas as permissões necessárias. 

Da mesma forma, um controle que exige várias aprovações para atividades para novos softwares pode ter sido justificado quando houve apenas algumas atualizações de software por ano e cada uma envolveu uma parte crítica de um sistema monolítico. Mas não deve exigir que duas dúzias de pessoas aprovem um pequeno ajuste - como alterar a cor dos usuários da tela. 

Com o software agora uma maneira importante de atender às necessidades de negócios e clientes em rápida mudança, os atrasos prolongados causados ​​por controles que se tornaram irrelevantes para colocar empresas em uma desvantagem competitiva fundamental. Os atrasos podem representar um risco de reputação e até mesmo um risco de sobrevivência se uma empresa for alvo de um ataque cibernético. (Ver " Desenvolva uma estratégia de segurança cibernética como se a existência da sua organização dependesse dela ,” October 2017.)

Governance is another area that requires adjustments in the move to DevOps. This includes adopting new approaches to funding. In agile, funding isn’t allocated on a project basis: for a set period of time, against a defined set of deliverables. Instead, funding is allocated to critical “products”—like a mutual fund company’s “my account” function or a retailer’s order-and-ship system—that require the attention De equipes por muitos meses ou até anos. Ferramentas. Na verdade, não existe uma resposta certa à pergunta de onde os direitos de decisão devem estar, para esta empresa ou qualquer outra. Mas é um problema que deve ser abordado no DevOps, que redesenham os limites do desenvolvimento de software ao longo de várias dimensões. Nas empresas que não adotaram totalmente o DevOps, não há uma filosofia de governança "você construiu, possui isso". Em vez disso, se surgir um problema envolvendo software que foi divulgado, as equipes de suporte de TI relatam -o por meio de um sistema de ingressos (como o ServiceNow), e a questão se torna de responsabilidade de uma equipe de manutenção de aplicativos. Mas o desenvolvedor original do código, tendo obtido um problema, pode voltar e tentar corrigi -lo. O resultado líquido é que, às vezes, as equipes de desenvolvimento e manutenção acabam trabalhando no mesmo software, ao mesmo tempo, resultando em inconsistências, problemas de integração e problemas de estabilidade. Por outro lado, em empresas que adotam práticas do DevOps, os problemas com o software lançado se registram automaticamente no backlog das equipes de desenvolvimento, que devem fazer as correções. Não há ninguém mais longe da linha que sequer pensaria em consertar o código e nenhuma possibilidade de diferentes departamentos tocando o mesmo código simultaneamente e trabalhando com propósitos cruzados. 

Another area where DevOps should trigger a governance change is in the decision rights related to cloud solutions. In the past, these decision rights belonged to the IT organization, and no one questioned that. But that’s changing as more business units create software directly using cloud-based tools. 

We saw questions about such decision rights at a company where digital product development teams were pushing for direct access to an Amazon Web Services account, and the IT operations group, concerned about standardization and security, was resisting. In truth, there is no single right answer to the question of where the decision rights should lie, for this company or any other. But it is an issue that must be tackled in DevOps, which redraws the boundaries of software development along multiple dimensions.

DevOps should also prompt a change in how companies deal with buggy software. At companies that haven’t fully adopted DevOps, there isn’t a “you built it, you own it” governance philosophy. Instead, if an issue arises involving software that has been released, IT support teams report it through a ticket system (such as ServiceNow), and the issue becomes the responsibility of an application maintenance team. But the original developer of the code, having gotten wind of a problem, may go back in and try to fix it. The net result is that sometimes both the development and maintenance teams end up working on the same software, at the same time, resulting in inconsistencies, integration problems, and stability issues. By contrast, at companies that adopt DevOps practices, issues with released software automatically register on the backlog of the development teams, which are expected to make the fixes. There is no one farther down the line who would even think of fixing the code, and no possibility of different departments touching the same code simultaneously and working at cross-purposes. 

Em última análise, o melhor teste de práticas de governança é o tempo de ciclo. Se as empresas puderem reduzir substancialmente o tempo entre quando planejam o software e quando o liberam de uma forma confiável e de alta qualidade, isso é um sinal de que seus processos de governança estão funcionando e que têm os recursos técnicos de que precisam. 

Redefine o papel do CIO e da organização de TI. Nas empresas que adotam modelos ágeis, as especificações para novos softwares - e o próprio trabalho de codificação - são a responsabilidade implícita das unidades de negócios. Se isso aliviar o CIO da responsabilidade por linhas individuais de código, na maioria dos casos ele ou ela ainda aders o fardo maior de qualidade. Ou seja, o CIO ainda deve recrutar e treinar desenvolvedores de software. Ele também deve implementar um modelo de entrega melhor, que inclua um ambiente operacional - padrões, serviços, processos, ferramentas e infraestrutura - que permite que os desenvolvedores maximizem sua produtividade. O CIO também deve carregar mais atividades no ciclo de vida do desenvolvimento de software.  If DevOps is to succeed, there must be changes—some subtle, some more dramatic—in the role of the chief information officer and the information technology organization. In companies that adopt agile models, the specifications for new software—and the coding work itself—become the implicit responsibility of business units. If this relieves the CIO of responsibility for individual lines of code, in most cases he or she still shoulders the larger burden of quality. That is, the CIO must still recruit and train software developers. He or she must also put in place a better delivery model, one that includes an operating environment—standards, services, processes, tools, and infrastructure—that allows developers to maximize their productivity. The CIO must also front-load more activities in the software development life cycle. 

O termo de arte para esse tipo de carregamento frontal é a “mudança à esquerda”, referindo-se a como alguém faria um diagrama de várias atividades em um gráfico de ciclo de vida de desenvolvimento de software. No DevOps, a equipe técnica que uma vez teria sido na função de operações de TI - cujas trabalhos entram em ação mais tarde - se mudaram para as equipes de desenvolvimento de produtos, onde têm uma opinião sobre como o código é construído. Também deve haver informações no início dos responsáveis ​​pela arquitetura de dados e à segurança cibernética de uma empresa. A mudança à esquerda da atividade e da experiência é uma das maneiras pelas quais todo o código que está sendo criado - geralmente em muitas unidades de negócios diferentes - pode chegar ao mercado rapidamente e com o nível necessário de segurança.  

Uma responsabilidade de CIO particularmente importante com o DevOps é a implementação de um ambiente de infraestrutura ideal. As equipes de desenvolvimento orientadas para os negócios precisam de plataformas independentes de infraestrutura, para que não precisem se preocupar com a compatibilidade. No DevOps, gerenciar isso e fornecer o kit de ferramentas de desenvolvimento de aplicativos são partes significativas da responsabilidade da organização de TI. 

Netflix, o serviço de vídeo de streaming global, fornece um exemplo do tipo de benefícios que podem vir do abraço do DevOps. A Netflix captura esses benefícios através dos esforços de um grupo central de operações de engenharia (uma espécie de equipe de TI especializada) cujo mandato é maximizar o desempenho do software recém -lançado e tornar as equipes de desenvolvimento de software mais eficientes. 

Na Netflix, os desenvolvedores se beneficiam de um conjunto comum de ferramentas, serviços e recursos de gerenciamento de infraestrutura - uma “estrada pavimentada”, como a Netflix chama - para atravessar o caminho normalmente esburacado para a nova criação de software. A estrada pavimentada e o grupo de operações de engenharia foram fundamentais para ajudar a Netflix a liberar um novo código - código confiável e seguro - para várias regiões geográficas em poucos minutos. Por exemplo, os arquitetos corporativos devem ter uma mão muito mais forte na definição da estratégia de arquitetura de TI, especialmente com relação às opções da plataforma. E as organizações de TI devem adotar mecanismos técnicos - como recipientes e microsserviços - que permitam que as equipes de codificação escrevam software reutilizável e o faça mais rapidamente. (Consulte os fundamentos técnicos de "DevOps '.")

Assisting and speeding up software deployments in this way require IT staff to develop skills they didn’t need previously. For instance, enterprise architects must take a much stronger hand in defining IT architecture strategy, especially with respect to platform options. And IT organizations must adopt technical mechanisms—like containers and microservices—that allow coding teams to write reusable software and to do it faster. (See “DevOps’ Technical Underpinnings.”)

Organizações de TI também devem adquirir alguns recursos técnicos novinhos em folha. Por exemplo, eles devem contratar ou desenvolver engenheiros de qualidade. Esses engenheiros devem ser incorporados na equipe de desenvolvimento de software e devem garantir que testes rigorosos ocorram no início do processo. A equipe de operações de TI também deve adquirir ou desenvolver novos conhecimentos, como o desenvolvimento de serviços de engenharia e infraestrutura de confiabilidade. Sem esses recursos, a entrega contínua e a integração contínua não são possíveis, tornando difíceis de alcançar a velocidade e a confiabilidade prometidas do Agile. 

Remake o modelo operacional através da automação. A automação, um dos pilares do DevOps, torna isso possível. Mas as decisões em torno da automação são complicadas, e sempre há a chance de que uma empresa demore um tempo para ganhar o pé. Por esse motivo, o WHERE e como a introdução da automação é uma decisão essencial para qualquer empresa que se mude para o DevOps. There is a huge benefit if a team, instead of going through a cumbersome approval process that might last weeks or months, can add a feature or plug a dangerous security hole with relatively little organizational oversight, and in the best case with just a few mouse clicks. Automation, one of the pillars of DevOps, makes that possible. But the decisions surrounding automation are complicated, and there is always the chance that a company will take a while to gain its footing. For this reason, the where and how of introducing automation is a key decision for any company moving to DevOps.

Um bom lugar para começar é com a automação de testes. Em nossa experiência, os benefícios de cobrir mais novos códigos por meio de testes automatizados podem, por si só, justificar uma mudança para o DevOps. Considere o risco sempre presente de atrasos em estágio avançado e os custos que eles criam. Com a cachoeira tradicional e até às vezes com o desenvolvimento ágil, os testes ocorre quando o código é concluído. Problemas significativos podem ser descobertos exatamente como o código deve ir ao ar. Por outro lado, no paradigma do DevOps, o código é desenvolvido iterativamente e testado regularmente. Isso torna menos provável que problemas de codificação surjam no último minuto. (Consulte o Anexo 2.)

Valioso como é, os testes automatizados devem ser lançados em estágios. As empresas devem começar com as partes de sua arquitetura, onde já começaram a fazer a transição para modelos ágeis. Depois de ter tido algum sucesso, eles podem usar a automação para cobrir mais seu código. 

Algumas das empresas que definiram o ritmo dos serviços digitais, como o Google, têm metas de confiabilidade bem acima de 99% - o que significa que eles esperam o software que lançam, com a ajuda de testes automatizados, para trabalhar imediatamente e em praticamente todas as instâncias. O Google, é claro, foi construído para permitir lançamentos rápidos de software e melhorias de serviços. Os nativos não digitais não precisam garantir confiabilidade na mesma escala, mas quando se trata de serviços digitais, eles podem aprender com o Google e outras empresas digitalmente avançadas - e devem. Afinal, uma empresa tradicional com um aplicativo digital crítico de missão-como uma empresa de serviços financeiros lançando um recurso de pagamento de smartphones-não pode mais lançar software ruim do que o Google.

Com os sistemas herdados das empresas tradicionais, como folha de pagamento ou planejamento de recursos corporativos, a dinâmica é necessariamente um pouco diferente. As empresas ainda podem fazer testes automatizados de seus sistemas herdados e, em muitos casos, já o fazem. Mas, para apoiar os ciclos de liberação mais rápidos que as equipes de desenvolvimento Agile esperam, os testes devem ser sincronizados com processos em lote, incluindo transferências e transações de dados pré -reagidados. Como os processos em lote geralmente são projetados para ocorrer da noite para o dia, a organização de TI também pode querer executar os testes automatizados da noite para o dia. Envolve muita mudança e treinamento e criaria muita interrupção com sistemas e produtos existentes. O DevOps precisa ser formado. 

Getting Started

Companies can’t just brush aside their current software development practices and make a wholesale move to DevOps; it involves too much change and training and would create too much disruption with existing systems and products. DevOps needs to be phased in. 

The first step should be to find an application that has low levels of dependency with other applications—perhaps a procurement portal for a manufacturing company or a savings platform for a bank—and run a pilot project to learn the DevOps model and fine-tune the practices. 

No piloto, uma equipe de desenvolvedores e engenheiros de TI estabelece um plano técnico - estabelecindo um repositório de código central e criando uma estrutura de teste para que a automação de teste possa iniciar. Uma vez que isso ocorre, a integração contínua e a entrega contínua podem começar. Esses processos possibilitam que a equipe de desenvolvimento se concentre no código de escrita e não na verificação manualmente de bugs e problemas de funcionalidade. 

Em empresas com sistemas herdados complexos, integração contínua e entrega contínua são duas fases separadas. Por outro lado, em nativos digitais, ambas as abordagens são essenciais para o desenvolvimento de software, e um nativo digital já pode estar pensando em outras maneiras de aprimorar o processo de liberação de software. Isso explica por que os desenvolvedores das empresas mais adeptas digitalmente veem que suas correções de código serão lançadas em dias, horas ou até minutos.  

O piloto DevOps não precisa continuar indefinidamente. Dentro de seis meses, deve ser possível ver benefícios. Eles geralmente assumem a forma de agilidade, que se traduz em mais lançamentos de software por semana; qualidade, que decorre do aumento da cobertura de testes; e eficiência, na forma de custos mais baixos de retrabalho e um aumento geral no número de processos automatizados. Após um período introdutório como esse, a empresa pode criar um roteiro para começar a aplicar práticas do DevOps a outras plataformas de software e infraestrutura e a outras partes de seu ambiente de tecnologia. O roteiro deve incluir uma decisão sobre o conjunto de ferramentas a serem usadas e a sequência na qual o DevOps será implementado em outras partes da empresa e em outras plataformas. de sua principal temporada de vendas. As atualizações anteriores haviam exposto a fragilidade do sistema, e os gerentes de negócios impuseram uma política de nenhuma alteração durante os períodos de pico. 

DevOps and the Customer

The example of a European travel company helps demonstrate why DevOps is turning into a must-have.

The company was unable to make pricing updates to its core booking system at the height of its main selling season. Previous updates had exposed the fragility of the system, and business managers had imposed a policy of no changes during peak periods. 

Não havia nada incomum na infraestrutura monolítica de software da empresa ou nas políticas para acomodá -lo. No entanto, a abordagem deliberada do desenvolvimento de software deixou a empresa incapaz de responder, na época mais importante do ano, a novos preços ou proposições de produtos dos concorrentes. Se uma viagem de sete dias a Belize fosse de repente sendo descontada para US $ 1.800 em outros sites de viagens, ele ainda estaria custando US $ 2.100 no site da empresa. As atualizações de preços dinâmicos exigiram uma alteração de software, mas o processo de liberação da empresa limitou a velocidade com que essas alterações poderiam ser feitas. Ao fazer isso, a qualidade de seus lançamentos de software e a resiliência geral de seu sistema melhoraram a tal ponto que a gerência elevou o congelamento da mudança. Posteriormente, a empresa pôde ser muito mais responsiva aos movimentos dos concorrentes durante a estação de pico do setor. Ou seja, eles verão que um de seus concorrentes está fazendo algo mais rápido, com menos problemas de segurança e qualidade e a menor custo. E eles precisarão tomar medidas para restringir a lacuna.

Recognizing that its software development processes were hurting the business, the company adopted some DevOps practices, including continuous integration. As it did so, the quality of its software releases and the overall resilience of its system improved to such an extent that management lifted the change freeze. Thereafter, the company was able to be much more responsive to competitors’ moves during the industry’s peak selling season.

Sooner or later, most companies are going to find themselves in a similar position. That is, they are going to see that one of their competitors is doing something faster, with fewer security and quality issues, and at lower cost. And they are going to need to take action to narrow the gap.

DevOps é uma maneira de fazer isso. A implementação do DevOps envolve mudanças de organização e processo que ocorrem bem à vista da maioria dos clientes. Mas os clientes esperam os benefícios. Para empresas que não entregam, pode não haver um
Segunda chance.