Sobre o autor
于洪奎Gerente Sênior do Centro de Software do Banco da China,
Analista de Sistema, CCEP, CSM, DevOps Master
14 anos de experiência relacionada ao desenvolvimento de software, incluindo 9 anos de experiência em gerenciamento de desenvolvimento
O que se segue é uma compilação da partilha do professor Yu Hongkui no DOIS 2018 · Estação de Pequim.
Venho de um departamento de desenvolvimento do Centro de Software do Banco da China. O Centro de Software do Banco da China começou a pilotar o desenvolvimento ágil de software e práticas relacionadas de CI e CD em 2013, e nosso DevOps interno real foi posterior a isso.
O DevOps do Bank of China envolve muitas linhas de produtos e pilhas de tecnologia. O compartilhamento a seguir não fornece uma introdução completa à abordagem DevOps do Bank of China. Incluirá apenas as práticas de DevOps de alguns produtos relacionados ao X86.
Meu compartilhamento inclui principalmente os seguintes quatro aspectos:
Primeiro, vamos dar uma olhada em todos. Quais são os chamados "instrumentos" e DevOps neste tópico?
Em segundo lugar , compartilhe com você nosso DevOps, o que é nosso DevOps? É a seleção de ferramentas e algumas reflexões gerais quando praticamos DevOps. Isso não quer dizer que nossa abordagem seja a melhor, mas sim compartilhar com você nossa abordagem. A chamada, a pedra da montanha pode ser usada para jade e jogue fora. Clique em "Pedrinhas" para sua referência.
Terceiro , compartilhe algumas coisas que achamos que fizemos com mais sucesso. Por um lado, mostraremos algo a você e, por outro lado, também aumentará a confiança dos colegas na prática de DevOps. Algumas coisas não são apenas alcançáveis por empresas da Internet. Na verdade, nossas empresas financeiras e grandes bancos também podem fazê-lo.
Quarto, para compartilhar algumas de nossas "lições do fracasso", costumamos dizer "Vamos lá, diga algo infeliz, faça todos felizes", isso também é para permitir que todos se divirtam e reflitam sobre isso. O chamado "fracasso é a mãe do sucesso", mas não basta o "fracasso", o mais importante é o aprendizado e a reflexão após o fracasso.
1. Dispositivo e DevOps
Em primeiro lugar, vou compartilhar com vocês esta imagem. Esta imagem é a entrada para o site de pesquisa de maturidade DevOps da Atlassian, que desenvolveu a famosa ferramenta de gerenciamento ágil Jira. O URL é: https://www.atlassian.com/devops / modelo de maturidade .
Por que compartilhar essa foto com todos? Acho que a descrição de DevOps nesta imagem é uma expressão melhor: quando olhamos para a palavra DevOps, o que você espera obter?
Todos nós estamos fazendo DevOps agora, e temos feito ágil há algum tempo. Acredito que muitos de nós devem ter pensado sobre isso. Para que estamos fazendo isso? E a partir dessa foto, há duas palavras que me fascinam muito claramente, expressando claramente o que esperamos obter do DevOps, a saber: "frequente" e "confiável" . Em última análise, fazemos DevOps, esperamos lançar nossos produtos de software aplicativo mais "alta frequência" e mais "estável". Este lugar contará duas histórias curtas.
O primeiro conto. No ano passado, enviei um questionário anônimo para um departamento de negócios de nossa sede. O conteúdo deste questionário é muito simples. O que você acha de nós como o departamento de desenvolvimento de software do Banco da China? Deve ser promovido ?
A primeira é que nossa entrega não é rápida o suficiente, devemos entregar mais rápido; a segunda é que não entregamos o suficiente, devemos fazer mais entregas; a terceira é que a qualidade da nossa entrega é ruim, devemos melhorar a entrega qualidade de nosso software; o quarto é que nossos custos de desenvolvimento são altos e o mesmo conteúdo de desenvolvimento que oferecemos é caro, devemos reduzir nossos próprios custos de desenvolvimento; o quinto é que a segurança do software que oferecemos é ruim, e devemos melhorar a segurança do software entregue. Eu me referi a esses cinco pontos como: mais, mais rápido, melhor, província e segurança . Dei esses cinco itens aos nossos colegas de trabalho e pedi que escolhessem um, até dois. Qual é o resultado final? O resultado é que mais de 90% dos colegas de trabalho pensam que estamos lentos agora e que devemos entregar mais rápido.
Muitas vezes as pessoas dizem que nosso setor financeiro é muito diferente de outros setores. Não somos a Internet. Portanto, nosso Agile e DevOps também devem ter suas próprias características. Concordo totalmente com esse ponto. No entanto, ser distinto não significa estar divorciado da essência.
DevOps em nosso setor financeiro não pode apenas aprender sobre a Internet e copiar as práticas de empresas de Internet, mas "primeiro você aprende a Internet e aprende como a Internet é rápida".
Eu sempre tenho um ponto de vista: todos os Agile e DevOps que não podem tornar a empresa mais rápida são hooligans. Se você quiser fazer DevOps e agile, primeiro você deve ser capaz de começar rápido. Obviamente, se esse jejum é rápido sustentável, é rápido constante.
O segundo conto, há poucos dias, tínhamos um salão de testes ágil com colegas do departamento de qualidade e do departamento de testes.Todos diziam que nossa qualidade foi "melhorada" com agilidade. Vou perguntar a todos, a qualidade realmente melhorou depois que praticamos o Agile? Em comparação com o desenvolvimento tradicional, como melhoramos? Todos vão sorrir com vontade.
Na verdade, em comparação com os departamentos e equipes de produto que usam métodos de desenvolvimento tradicionais, a qualidade de entrega de software dos departamentos de desenvolvimento e equipes de produto que usam métodos ágeis não melhorou, pelo menos a partir de nossos dados internos.
O Agile não melhorou a qualidade de entrega de nossos produtos de software. Mesmo assim, você descobriu que quando começamos a fazer agile, nossa entrega realmente começou a ficar mais rápida, mas nossa qualidade de entrega piorou. Isso não é um sentimento, é. Dados suportados.
No entanto, com o passar do tempo, a qualidade da entrega de produtos ágeis é gradualmente e significativamente melhorada, e alguns se aproximam do nível de qualidade de entrega dos métodos de desenvolvimento tradicionais, que também são suportados por dados. Na verdade, não há confusão sobre isso. O modelo da curva de mudança há muito explica isso. O guru da administração Peter Senge também disse: Primeiro piorar, depois melhorar.
Por meio dessas duas histórias curtas, acho que esta é uma interpretação muito boa de nossas demandas por Agile e DevOps, seja do nosso lado comercial ou de nós mesmos, todos esperamos entregar nossos produtos de software com mais frequência e mais rápido. No entanto, essa entrega também deve ser alta -qualidade e robusto.
Costuma-se dizer: Agile e DevOps não são rápidos. Estou falando sério que esta frase não é precisa.Eu concordo com uma afirmação precisa: Agile e DevOps não são apenas rápidos , mas antes de tudo, eles devem ser rápidos .
Quando se trata de DevOps, existem vários conceitos que todos podem conhecer melhor, como ágil e enxuto. Quero compartilhar aqui, em um sentido estrito, qual é a relação entre esses conceitos. Em primeiro lugar, falando de maneira geral, seja Agile, Lean ou DevOps, ele nunca admite que se concentra apenas em um parágrafo e diz que é ponta a ponta. Um DevOps típico tem loops infinitos, e Lean não Independentemente da parte de trás, o Agile não diz que não liga para a parte da frente. Estou falando em um sentido restrito aqui. A primeira vez que ouvi esse ponto foi do professor Li Jianhao, do Halo. Em um sentido restrito, esses conceitos se parecem com a imagem abaixo durante nosso processo de desenvolvimento.
Meu resumo desta imagem é: Lean está mais focado em fazer as coisas certas, Agile está mais focado em fazer as coisas rapidamente e DevOps está mais focado em fazer as coisas suavemente . Por falar em Lean, recomendo dois livros a todos, um é "Lean Entrepreneurship" e o outro é "Lean Data Analysis". Na perspectiva do Lean, continuaremos a explorar o valor do negócio e a pesquisar através do processo de aprendizagem, construção e feedback. O valor comercial consiste em explorar e encontrar constantemente o ponto de valor "certo". A "produção enxuta" aqui é realmente diferente da "produção enxuta" original.
Todos sabem que o Agile foi iniciado por um grupo de mestres de desenvolvimento desde a origem. Eles estão essencialmente mais preocupados em "buscar métodos melhores de desenvolvimento de software". Eles também disseram no início que queremos agregar valor ao cliente e oferecer software viável, resposta às mudanças, eles não disseram que eu não estou preocupado com outras coisas.
Apenas no sentido original e restrito, o Agile presta mais atenção aos métodos de desenvolvimento de software e menciona menos sobre a busca de valor na frente e a entrega suave atrás.
Não vou falar muito sobre DevOps, já falei muito. Eu falarei sobre isso mais tarde. Vamos falar sobre “uso de ferramentas” novamente. O termo “uso de ferramentas” é um termo muito antigo. No início, as chamadas “armas” se referem a armas e “uso” se referem a ferramentas agrícolas. Mais tarde, tornou-se uso de ferramentas Nossa civilização chinesa é ampla e profunda, e cada palavra tem isso. Há muitas explicações. Aqui me refiro ao uso de "ferramentas" para me referir ao uso de ferramentas, e não há outro significado profundo.
Isso se relaciona com a nossa visão ao entender as ferramentas?
Cultura e comportamento, todos nós sabemos que a cultura afeta o comportamento, e o comportamento, por sua vez, afeta a cultura, mas quando introduzimos ferramentas, na verdade é a mesma coisa. Você acha que está usando ferramentas por meio de seu próprio comportamento para afetar as mudanças nas funções de Ao mesmo tempo, por sua vez, as ferramentas afetarão, regularão e até guiarão seu comportamento.
2. Nosso DevOps
Acima falamos brevemente sobre os dois conceitos de DevOps e ferramentas. A seguir está o DevOps do Bank of China. Todos estão muito preocupados ou esperam saber como é o DevOps do Bank of China. Vamos compartilhar com você aqui. Claro, isso está relacionado apenas às nossas partes relacionadas ao X86.
2.1 Seleção de ferramentas
Eu sempre disse que as ferramentas são tão refinadas quanto são. Vamos dar uma olhada no que estamos falando quando falamos sobre ferramentas.
Existem muitas cadeias de ferramentas DevOps. Estes são apenas alguns deles, e não há muitos deles. Existem muitos mapas de cadeia de ferramentas estilo metrô, estilo teia de aranha e até mesmo tabelas periódicas. Você pode consultar o Sr. Artigo "Um artigo contém 16 mapas" de Xu Feng. Artigo "Revisão e revisão de fotos" do DevOps.
Entre eles, muitas pessoas devem conhecer esta foto, esta é uma foto muito usada, de James Bowman. Esta imagem é altamente recomendada para que todos entendam. De frente para trás, existem vários campos em cada link, e cada campo tem algumas ferramentas de código aberto que recomenda ou pensa que todos deveriam usar. Entre essas ferramentas de código aberto, o Bank of China usa muitas delas.
Basicamente, usamos todas as ferramentas de código aberto e não aberto que foram marcadas. O que quero dizer é que não importa qual ferramenta é útil, o que importa é como você a escolhe e usa no processo, e se é verdade. Resolveu seus próprios problemas com ferramentas!
2.2 Cadeia de ferramentas Devops
O quadro acima é muito complicado, do ponto de vista do usuário, nosso processo é assim, provavelmente usamos essas ferramentas durante todo o processo, desde os requisitos anteriores até o acompanhamento posterior. O que precisa ser mencionado repetidamente aqui é que isso está relacionado apenas à nossa parte X86.
3. Compartilhamento de experiências bem-sucedidas
3.1 Código fonte
Todos nós sabemos que existem disputas entre o SVN e o Git na indústria. Alguns dizem que o SVN é bom, e outros dizem que o Git é bom. Qual você acha que é a diferença entre o SVN e o Git? Ou o que você defende?
画外音：其实此处的互动，见仁见智，并没有标准答案！
No desenvolvimento real, meu departamento usa SVN e alguns de nossos departamentos usam Git. Qual ferramenta é melhor, minha resposta é: "Mainline development is better!".
Responda completamente à pergunta errada! Este é o primeiro ponto do que acreditamos ser uma prática de sucesso que quero compartilhar: desenvolvimento de linha principal. Todos nós sabemos que para melhorar a eficiência do trabalho é muito importante eliminar o desperdício.
Então, qual é o desperdício no desenvolvimento de software? Todos nós sabemos: troca de trabalho, comunicação ineficaz e equipar os desenvolvedores com máquinas ruins e telas pequenas. Aqui, gostaria de mencionar que muitas pessoas discordam, mas o desperdício óbvio é a fusão de ramos. Em ágil e enxuto, diremos que queremos gerar valor. Pense na fusão de ramos no processo de desenvolvimento de software e no que os usuários são gerados . valor? Nenhum valor de usuário é gerado.
Sempre tive um ponto de vista: a chamada fusão de ramos, no atual ambiente de tecnologia de TI, é apenas uma ação desnecessária no processo de desenvolvimento de software que não produz nenhum valor. Existem apenas duas razões pelas quais você não pode eliminá-lo. Em primeiro lugar, você não quer, porque está preso à sua imaginação e sente que deve fazê-lo; em segundo lugar, você é incompetente e tem poucas habilidades, e você só pode compensá-lo pelos chamados meios de "gestão".
3.2 Gestão de Filiais
A foto acima é a nossa antiga filial, você pode imaginar? Esta é a nossa produção lote a lote. Este é o nosso status de filial anterior. Para este status de filial, um gerente de projeto especial desenhou um gráfico para gerenciamento. Excelente! ?
Esta é a estrutura revigorante que obtivemos depois de mais de meio ano de muito trabalho depois de percebermos esse problema. O que quero dizer a todos é que isso pode ser feito e pode ser feito. Porém, é realmente difícil.
Quando vimos o desenvolvimento do backbone, muitas pessoas no setor sabiam disso, mas o que exatamente é o desenvolvimento do backbone? O chamado desenvolvimento de tronco ideal, primeiro todo o código é submetido ao ramo de tronco, e depois sua liberação pode ser liberada do tronco a qualquer momento, isso pode ser muito difícil de fazer, você precisa manter seu tronco bem estável, isso requer você A equipe é autodisciplinada o suficiente. Todos que enviam código são autodisciplinados o suficiente. Sua integração contínua é robusta o suficiente e bem mantida.
O que fazemos é uma espécie de desenvolvimento de tronco realista, ou seja, seu envio ainda é submetido ao tronco, mas você deseja liberar. Quando quiser liberar, você puxará um branch deste local para liberação. Ao liberar, lá não será mais do que um galho. Votei durante a iteração. Depois da votação, o galho congelou. Apresentei um modelo muito vivo. É como uma árvore. Está crescendo. Essa é a principal situação de desenvolvimento que estamos fazendo agora. No entanto, o desenvolvimento do backbone é realmente muito difícil.
A imagem acima é um ramo de gerenciamento de versão frequentemente usado na indústria, e já tínhamos feito isso. Esses dois métodos são definitivamente diferentes, e as melhorias de valor e eficiência que eles trazem para você também são completamente diferentes.
Diz-se que a espinha dorsal é bem desenvolvida, mas as moedas sempre têm dois lados. Quais são os efeitos colaterais disso? Qual é a sua dificuldade? Pense nisso, todos.
Costumamos fazer intercâmbios com a indústria, todos dirão que isso é bom quando eu apresentar o desenvolvimento de backbone! Ok, por que você não faz isso? Todos vão sorrir com muita consciência, não podemos fazer isso! Somos especiais, temos esse motivo, esse motivo, Barabara ...
Neste momento, se nos perguntarmos, por que não podemos fazer isso? Como eu posso fazer isso? Se realmente quisermos fazer isso, qual será o primeiro passo, o menor passo e a mudança real?
Quando me comunico com muitos colegas do setor, especialmente nossos colegas financeiros, desenvolvemos um estado.Uma palavra mencionada no "Guia de prática de DevOps" é chamada de desamparo aprendido , consulte "Guia de prática de DevOps" na página xxii. Para "fritters antigos" que trabalharam na área de TI financeira por mais de dez anos como eu, ouvi um termo mais apropriado chamado incompetência sofisticada . O desenvolvimento desse estado é causado pelo meio ambiente, por um lado, e pela própria pessoa, por outro. Quando fazemos DevOps, devemos primeiro estar cientes desse problema.
Lá quando você Mangmangdaodao, na verdade, muito trabalho para fazer apenas o que você pode fazer, no entanto, não é necessariamente o que você deve fazer . Porque muitas vezes achamos que as " coisas que deveriam ser feitas " são muito difíceis, então tomamos a iniciativa e desistimos quando a ideia é apenas uma ideia.
Desenvolvimento principal, quero dizer que não é fácil amar você
-
Ciclo iterativo suficientemente curto (duas semanas, pronto para a versão de produção)
-
Prazo de execução curto o suficiente para produção (três dias úteis)
- Desesperado para garantir a série
O desenvolvimento de tronco é algo que absolutamente deve ser feito, mas também é absolutamente difícil, especialmente no setor financeiro. Para atingir o desenvolvimento do backbone, é necessário um ciclo de iteração curto o suficiente e um lead time curto o suficiente para a produção. Esses dois pontos são suficientes para desestimular muitos colegas financeiros, além de uma sequência de demanda garantida. Bem, basicamente desista completamente.
O que quero dizer a todos é que isso pode e deve ser feito .
3.3 integração contínua
O que é integração contínua?
-
Os desenvolvedores enviam o código pelo menos uma vez por dia
-
Acione a compilação e teste imediatamente após o código ser enviado
- Trate o mais rápido possível após a falha de construção e teste
Integração contínua não é um vocabulário novo. Todo mundo está falando sobre integração contínua. Esta é a integração contínua na minha definição. Esses três itens definem claramente o efeito que deve ser alcançado depois que a "integração contínua" for alcançada. Mesmo esses pontos não atendem aos requisitos mínimos, geralmente não chamo isso de integração contínua. Já vi mais integração dita contínua, mas na verdade, só a segunda pode ser alcançada.Este tipo de integração contínua deveria se chamar: construção automatizada.
O ponto que estou focando aqui é, "Processando o mais rápido possível após as falhas de compilação e teste", o que significa "processamento o mais rápido possível"? Em nossa definição, lidar com isso o mais rápido possível é: o painel fica vermelho e não sai do trabalho. Uma tela de exibição é colocada perto de cada equipe de desenvolvimento de produto em nosso departamento, que chamamos de painel físico. Depois de vários anos de trabalho árduo, podemos finalmente fazer isso agora: o painel fica vermelho e não funciona.
大家想想这一条规则或者叫做纪律会有什么副作用？
Sim, para sair do trabalho, todos enviarão o código com antecedência. Você pode enviar o código às quatro da tarde. Nós permitimos. Não nos importamos que os desenvolvedores enviem o código às quatro da tarde.
"Lide com isso o mais rápido possível" embora pareça uma frase vaga, mas temos definições, regras e disciplina claras para apoiá-la.
Somente se você fizer cada uma das opções acima, a integração contínua se tornará significativa.
Teremos disciplina de integração contínua, o que parece muito simples, mas não é tão simples quanto imaginamos para realmente fazer a disciplina obedecer a todos e se tornar um hábito de todos. Não é que um gerente possa falar sobre isso, pregar, puxar um banner promocional e fazer isso, ele precisa tomar ações concretas.
Como fazer isso Deixe-me falar sobre nossa abordagem. Pode não ser adequada para todos, mas você pode ouvi-la.
Temos um painel físico como a imagem abaixo. Este painel físico é muito simples de construir. Eu acredito que você pode fazer isso em apenas um dia e meio de pesquisa. Este painel físico é colocado perto da equipe de desenvolvimento. As coisas físicas têm um efeito natural de radiação de informação, ou seja, elas estão lá se você quiser ver ou não. Este é o primeiro passo e o passo mais fácil.
A segunda etapa é treinar todos. Realizamos muitos treinamentos para dizer a você como escrever testes de unidade e que tipo de testes de unidade não farão com que o painel fique vermelho devido a outros problemas complicados, como dados e ambiente.
O terceiro passo é passar o primeiro momento difícil com a equipe como gestor e promotor da cultura.
Deixe-me contar uma pequena história. Em agosto de 2017, tínhamos quatro produtos da equipe Scrum para desenvolvimento fechado em Xi'an. Setenta ou oitenta pessoas trabalham seis dias por semana. Todas as noites até as 10 horas, fui convidado para ir como um treinador interno. A equipe de treinamento, quando eu fui, o painel estava sempre vermelho. Demorou quase duas semanas. Passamos por três sessões de treinamento e passamos pela fase de consertar todos os tipos de problemas complicados que faziam o painel ficar vermelho. Ao meio-dia do dia 24 de agosto, ainda me lembro claramente dessa data e tudo está pronto, resolvi iniciar a disciplina de trabalho “o painel fica vermelho sem sair sai do trabalho”, e anunciei a todos.
Na verdade, ainda me sinto muito imaginário em meu coração. Tenho trabalhado até as dez da noite. Se ficar vermelho, eu realmente não posso consertar. Será que realmente deixo todo mundo ir a noite toda? Se for esse o caso, me sinto um pouco irracional. Lei de Murphy! Quando todos chegaram às 9h30, todos começaram a enviar o código. De repente, o painel ficou vermelho e todos ficaram chocados e eu também estava nervoso.
Digo a todos, parem todo o trabalho, ainda temos meia hora para sair do trabalho, consertar o mais rápido possível, podemos sair do trabalho depois do conserto. Ocupado por um tempo, várias buscas às 10:20 da noite, o painel foi consertado e todos se aplaudiram espontaneamente. Desde então, a equipe de produto sempre manteve a disciplina de trabalho de "o painel fica vermelho e não funciona" por um ano.
O que quero dizer a todos é que no processo de implementação da integração contínua, o mais importante é o estabelecimento de regras de trabalho de integração contínua e disciplina de trabalho, e as melhores ferramentas e plataformas são construídas.
E quando você quer introduzir uma regra e estabelecer uma disciplina, você deve definir exatamente como quer fazer isso. No processo, você precisa treinar todos, deixar que todos percorram o caminho com todos, como localizar e reparar a possibilidade o mais rápido possível Então faça algo para reforçar esse comportamento.Você tem que realmente participar do processo como participante, acompanhar a todos no primeiro e segundo momentos difíceis, e então, naturalmente, você alcançará uma nova equipe Hábitos e disciplinas são os o chamado estabelecimento de uma nova "cultura".
Em muitos casos, os treinadores ou gerentes são "incultos", mas gritam todos os dias para construir e mudar a cultura. Especificamente neste assunto, o esclarecimento cultural para coaches ou gestores é: os coaches ou gestores devem aprender a "sujar" as mãos. Em suma, eles devem fazer isso com todos! A cultura é feita, não gritada e postada em banners publicitários.
Dito isso, você acha que as ferramentas que usamos no processo de coleta contínua acima ainda são tão importantes quanto você pensava antes?
3.4 Implementação automatizada
A implantação automatizada é a dificuldade persistente de todos:
-
Dificuldade na integração do gerenciamento de permissões do ambiente de produção
-
Difícil de coletar parâmetros de configuração do ambiente de produção
-
Dificuldade na vinculação de mudanças de recursos do ambiente de produção
-
O suporte incremental e total é difícil de unificar
- Difícil de implementar padrão de pacote automático
A refeição deve ser comida uma mordida de cada vez. Em 2016, escrevemos na meta anual de qualidade do departamento: Todos os produtos são embalados automaticamente e o agrupamento manual de embalagens é estritamente proibido. Em certo sentido, a montagem manual de pacotes é um desperdício de recursos organizacionais, por isso promovemos fortemente a montagem automatizada de pacotes internamente. Então, há nossa implantação automatizada.
Em todo o centro de software, existem agora mais de 20 produtos que foram implantados automaticamente. Nossa meta este ano é mais de 100. Não sei se isso pode ser alcançado. No entanto, mais de 20 produtos foram implantados automaticamente, incluindo X86 e assim por diante. Todas as plataformas realizaram implantação automatizada.
Em comparação com o tempo de implantação manual, a implantação automatizada ficará mais rápida. Na verdade, mais rápido é apenas uma pequena parte do lucro. O mais importante é que você está bebendo café durante a implantação automatizada e geralmente não há erros. Pense no implantação manual. Neste caso, o que os alunos de operação e manutenção estão fazendo? Os dedos voaram, franzindo a testa. Comparando as duas situações, a felicidade e a estabilidade são absolutamente diferentes.
A implantação automatizada é algo que devemos nos esforçar para fazer quando fazemos DevOps, mas quando fazemos a implantação automatizada, automatizamos o agrupamento de pacotes, gerenciamento de ambiente, gerenciamento de parâmetros e gerenciamento de autoridade. Se o seu data center e o centro de desenvolvimento ainda estiverem separados, esses são todos pontos que você precisa superar, e cada um não é simples. Isso é muito complicado, não vou entrar em detalhes. O que quero dizer é que a implantação automatizada é algo a ser feito para superar várias dificuldades, e é algo que deve ser feito.
4. Retrospectiva e reflexão sobre o fracasso
Deixe-me falar sobre nosso fracasso e reflexão.
O sofrimento do teste funcional automatizado:
-
Em 2016, vários produtos compilaram mais de 1.000 casos de teste funcional automatizado orientado para UI (Robot Framework) .Depois de meio ano, todos eles foram abandonados e não foram executados novamente.
- Um grande número de casos de teste funcionais automatizados orientados para IU escritos por um produto geralmente levam de uma a duas semanas para serem concluídos depois de executados . Existem 2 a 3 desenvolvedores de teste responsáveis por executar e escrever, bem como atualizar esses casos.
Vendo todos os sorrisos cúmplices, sei que nosso status quo não é especial. Já passamos pelos mesmos sofrimentos de todos. As empresas de Internet nos deram um bom exemplo, mas infelizmente não podem nos salvar. Nosso ambiente é diferente.
Pelo que eu disse, você sabe que todos esses processos de agendamento de tarefas são completamente diferentes daqueles de empresas de Internet. Alguns gerentes de produto de empresas de Internet obtêm um PPT, mostram-lhes o topo e começam a fazê-lo. É hora de pegar pessoas. Nós deveríamos pedir dinheiro e pedir dinheiro. Nós do setor financeiro, temos uma demanda, desde a avaliação até a implantação de um projeto bem-sucedido, não um ano ou meio de um ano é impossível descer, e os que podem cair são velozes.
Voltando ao teste automatizado, o acima exposto é um “sofrimento” que temos nos testes automatizados.Depois do sofrimento, temos reflexões. A mesma frase: Faça o que deve ser feito, não faça apenas o que é fácil de fazer.
Porque, em muitos casos, as coisas que você acha que deveriam ser feitas e não são fáceis de fazer são os pontos-chave da melhoria do sistema. Caso contrário, por que você fez tantas coisas capazes e o sistema ainda não tem melhorias?
O que fazer? Encontramos esse ponto no diagrama de transição comparativo de uma organização de alto desempenho e uma organização de baixo desempenho que foi publicado.
Nós o lançamos a cada 10 a 100 dias. Este é nosso status atual. Você verá que a organização, o desenvolvimento e os testadores neste estágio estão trabalhando juntos para manter casos de teste automatizados e a automação que mencionamos acima para casos de teste funcionais , o primeiro desenvolvimento é escrito por mim e o segundo é escrito por testadores especializados em testes automatizados. O único não é escrito e mantido juntos.
Quando percebi isso, foi uma grande inspiração para mim na época. Eu queria encontrar o que fazer. Ouvi pessoas dizerem que precisamos testar a migração, desenvolver e testar a integração, mas o que é integração? Como integrar?
Use o tópico de teste automatizado para integrar desenvolvimento e teste. Quando os casos de teste automatizados são mantidos em conjunto, o desenvolvimento e o teste são integrados.
O que é a manutenção conjunta de casos de teste automatizados? O que exatamente é "manutenção conjunta"?
Ponto mais intuitivo: o desenvolvimento e o teste compartilham o código do teste automatizado e modificam em conjunto o código do teste automatizado. Às vezes, gostamos especialmente de dizer algumas palavras vagas e abstratas, porque essas palavras fazem com que todos tenham uma vaga sensação de segurança.
Da integração de desenvolvimento e teste à manutenção conjunta de casos de teste automatizados e ao compartilhamento de código de teste automatizado, todos podem sentir a diferença. Na verdade, não é tão fácil encontrar esse ponto-chave, mas não é tão difícil.
Encontrar é apenas o primeiro passo, e alcançá-lo é importante. Esta é outra jornada difícil. Quanto desenvolvimento e teste estão no mesmo departamento? Quantos testes são capazes de codificar? Acredito que, quando fiz essas duas perguntas, muitas pessoas desistiram silenciosamente em seus corações.
Nosso desenvolvimento e teste pertencem a dois departamentos diferentes, e nossos testadores basicamente não têm habilidades de codificação. No entanto, estamos fazendo isso: ao compartilhar o código de teste automatizado, o desenvolvimento e o teste em conjunto mantêm interfaces automatizadas e casos de teste funcionais, formando a integração de desenvolvimento e teste. Porque é isso que deve ser feito .
Quando se trata de escrever casos de teste automatizados, há um tópico de aumento de casos e quantos casos.
Aqui, estamos implementando uma disciplina, ou seja: ao adicionar testes automatizados, você deve garantir que seus casos de teste automatizados sejam continuamente eficazes e utilizáveis. Como chamá-lo de contínuo, eficaz e utilizável?
É um aumento de casos de teste de função automatizados, que devem ser capazes de
-
Corra pelo menos uma vez por dia
-
Espera-se que a operação seja 100% bem-sucedida
- Se falhar, deve ser devido a problemas de aplicativo, não a problemas de não aplicativo, como ambiente e dados
Eu chamo isso de: o aumento disciplinado em casos de teste automatizados,
Casos de teste para a função de automação adicionada (interfaces também são contadas), executados pelo menos uma vez por dia. Casos de teste automatizados que não podem ser executados uma vez por dia são basicamente decorações. Além de fazer seus gerentes se sentirem atualizados toda vez que olham para o número de casos, eles não têm uso prático.
Espera-se que cada execução seja 100% bem-sucedida. Se não for bem-sucedida, deve ser porque seu aplicativo tem um problema, não por causa de problemas de dados ou ambientes instáveis. Outros sistemas estão inativos, então temos tempo de inatividade. Espere um minuto.
Somente se o primeiro caso atender a esta condição, o segundo caso poderá ser escrito, e somente se ambos os casos atenderem a esta condição, o terceiro caso poderá ser escrito. Se o primeiro caso não atender às três condições acima, tente encontrar uma maneira de fazer com que o primeiro caso atenda às três condições acima.
Isso é chamado de disciplina e isso é chamado de contenção . Agora, somos muito cautelosos ao aumentar nossos casos de teste automatizados e exigimos que nossos testes sejam integrados à nossa equipe para escrever casos de teste automatizados conosco.
Nossos casos de teste de interface são basicamente escritos por testadores em iterações com o suporte de desenvolvedores. O que devo fazer se não conseguir escrever primeiro? Treinamento! Estude!
Por falar nisso, o teste de unidade tem um princípio chamado de princípio FIRST e, às vezes, é chamado de princípio AIR no teste funcional. Acho que adicionar um A é um pouco redundante. Acho que o teste funcional automatizado deve atender ao princípio SIR . Qual é o Princípio SIR? Você descobrirá que, na verdade, não há F e T do princípio FIRST de teste de unidade .
O que é F? F é rápido. Você descobrirá que seus testes de unidade serão rápidos. No entanto, em qualquer caso, o teste automatizado de interface e o teste funcional automatizado são difíceis de serem tão rápidos quanto o teste de unidade.
T é Timely, o que significa que pode ser escrito a tempo. Seu teste de unidade é escrito por seu próprio desenvolvimento e, às vezes, você pode usar TDD. Há Timly suficiente, mas o teste automatizado de suas classes funcionais e classes de interface não é necessariamente It pode ser escrito em oportuna.
Todos, eu acho que o teste funcional automatizado deve satisfazer o princípio SIR .
Esta é a nossa reflexão e ação após uma série de fracassos, ainda não se considera que tenha havido resultados, o processo também é muito difícil, mas continuaremos a fazê-lo.
Dito isso, não sei se todos têm visões diferentes sobre a "abordagem" no DevOps. Imite o corpo geral do Manifesto Ágil e, finalmente, dê a você uma mensagem:
As ferramentas são importantes, o que é mais importante?
Esta questão é deixada para todos pensarem e resumirem.
注：本文仅代表个人观点。
Como um dos bancos com a história mais longa na China, o Bank of China foi aprovado na avaliação "Padrão DevOps - Capacidade de Entrega Contínua Nível 3 do Modelo de Maturidade da Capacidade de Integração de Operações e P&D"!