Até que a convenção "Sobre a proteção dos direitos de uma pessoa desumana" seja adotada, você precisará usá-la e dar a rotina de trabalho aos bots. Faz sentido começar agora, ou depois de cinco anos, a revolta dos carros começará, ações em massa para insultar os sentimentos de bots com tarefas chatas preencherão os tribunais para regular as relações homem-máquina. Então se apresse.
Rotina conservadora e método de trabalho, adesão servil a um padrão estabelecido, se transformaram em um hábito mecânico. 6 letras.
Existe um trabalho que você não quer fazer, mas precisa. Este artigo não terá inserções grandes com código e instruções sobre como criar seu bot a partir do zero. É melhor dizer como o processo de lançamento funciona na nossa Pizza Dodo, como automatizamos e agilizamos, dando uma parte da rotina chata ao nosso bot escrito em C #. Vou prestar atenção à funcionalidade e lógica do bot. Vai ser legal se esse material o inspirar a escrever para seu assistente, que facilitará a vida de você e seus colegas.
Alguns anos atrás, lançamos um lançamento uma vez por semana. Em maio de 2018, com uma taxa máxima de 147 horas para lançamento, estabelecemos uma meta de lançamento todos os dias. Agora nosso mínimo: quatro horas para liberar, mas isso não acontece com frequência. Queremos consertar o registro e poder reduzir todo o processo ao pressionar um único botão.
Ciclo de liberação
Agora, no Dodo IS, sete equipes se revezam lançando um lançamento. Uma pessoa da equipe torna-se "sortuda" - os que estão no local. Ele é piloto de um avião: ele tem um monte de alavancas e dispositivos que ele deve usar com habilidade para lançar as próximas atualizações. Pensamos e decidimos: "É hora de fazer um piloto automático, e é melhor gastar nosso tempo com algo mais emocionante do que preencher tabelas chatas com estatísticas e acompanhar as execuções de testes automáticos".
Então, para se tornar um relisman, é necessário que a vez chegue ao seu time. Para que tudo fique claro e ninguém fique confuso, colamos adesivos com os nomes das equipes na parede. A equipe de lançamento recebe uma coroa honorária, com a qual nos movemos a cada vez.
Depois de receber a
marca preta da coroa
, o Relismain deve se lembrar de onde está a lista de verificação das etapas de lançamento. Além disso: lembrou -> encontrado -> criou uma cópia do modelo e, finalmente, abriu a lista de verificação no sistema Kaiten. Kaiten é uma placa eletrônica na qual, na forma de cartões, colocamos e monitoramos o status das tarefas em desenvolvimento. Para novos desenvolvedores, esse procedimento como um todo era muito óbvio. E como você sabe onde procurar esta folha de verificação e por onde começar quando não há pistas?
Tendo reunido nossa vontade em um punho, decidimos que era o suficiente para suportá-la. É hora de dar parte da rotina chata ao bot. Quem se não nós? Quando, se não agora?
O que conseguimos automatizar
A decisão foi tomada, é hora de começar a projetar nosso piloto automático! Tendo encontrado a API do Kaiten aqui:
https://faq.kaiten.io/docs/api , com apenas uma solicitação, criamos um cartão para os novos revendedores.
Agora, este cartão precisa ser entregue à equipe que lançará o próximo.
A lógica aqui é:
- A versão anterior completa a versão digitando um comando para o bot no Slack.
- O bot pega o ID do Relisman no Slack e procura em qual equipe de desenvolvimento nosso sortudo está. Para fazer isso, o bot percorre os grupos de usuários do Slack e analisa em qual deles consiste o nosso relé.
- Tendo encontrado o grupo, o bot verifica qual equipe será lançada em seguida e envia um alerta para o chat geral. Na mensagem, o bot fornece cuidadosamente um link para a lista de verificação já criada, para que você não vá a lugar nenhum.
Ótimo! Agora temos uma idéia do que fazer em seguida. Abrimos a lista de verificação, veja: “Crie um canal para lançamento no Slack, convide todas as equipes cujas alterações estão no lançamento e descubra se elas precisarão de testes manuais.” Resta ensinar isso ao nosso bot.
Abra a documentação da API do Slack aqui
https://api.slack.com e procure um método para criar um canal lá.
Como você pode ver, no Slack, como em outras ferramentas, não há nada complicado. Tudo se resume ao envio de uma solicitação POST com dois parâmetros obrigatórios (esses são os opostos aos que diz ser obrigatório). Na solicitação, precisamos passar o nome do canal criado (nome do parâmetro) e o token de autorização (token do parâmetro). Preste atenção à linha "Funciona com: Tipo de token - usuário, escopo (s) necessário (s) - canais: gravação".
O Slack possui dois tipos de tokens: emitidos pelo usuário para usuários e emitidos pelo bot para aplicativos. Ao emitir um token, determinamos quais direitos de aquisição de seu proprietário. Para criar canais, precisamos de um token de usuário (tipo de token - usuário), que tenha direitos para gravar canais (canais: write).
Quero observar uma nuance de nosso envio de mensagens para o Slack. Inicialmente, não pensamos no que faríamos se algo desse errado. Recrutamos uma equipe no Slack e ela executa todas as tarefas que colocamos nela. E o que acontecerá se em uma das tarefas a equipe cair? No nosso caso, a resposta foi: "nada". E isso é ruim. A solução para nós foi escrever no bate-papo de liberação qual ação está sendo executada no momento e, se o comando não tiver sido concluído, relate um erro no bate-papo e registre o erro.
A segunda solução bem-sucedida foi conectar o banco de dados no qual armazenamos o status da execução das ações dos comandos. Agora, após iniciar um novo release usando o comando “/ startregress”, não temos medo de que algo caia e, quando você o chamar novamente, os comandos serão executados desde o início pela segunda vez. Não precisamos criar um novo canal no Slack toda vez, fazer uma solicitação pull, etc. Criamos um canal no Slack - registramos o status de execução bem-sucedida no banco de dados e não retornamos mais a essa ação.
Então, agora, clicando em um botão, criamos um canal de lançamento e convidamos todos os participantes cujas tarefas serão liberadas.
Os próximos na fila foram a integração com o Github e o TeamCity. Trabalhamos no Gitflow. Quando queremos liberar, usamos o ramo DEV, o working = green = no qual os testes passam, e a partir dele criamos o ramo de lançamento.
Para fazer isso, nosso bot vai para o TeamCity, olha lá para iniciar uma execução de teste para o ramo DEV. Se os testes forem verdes, como grama perto da casa, vá para o GitHub, crie um ramo de lançamento e uma solicitação de recebimento!
Ao criar uma solicitação pull, precisamos adicionar uma descrição das alterações que estamos lançando. Então Kaiten vem em nosso auxílio. Nosso bot cria uma coluna com o nome do release, pega tarefas da coluna DEV e as move para o release. Então, sabemos e vemos o que será fundamentado conosco. Após a mudança, o bot copia os nomes dos cartões e os adiciona à descrição da solicitação de recebimento com referência aos próprios cartões. Agora, podemos ver em cada versão quais tarefas foram executadas e, ao abrir o cartão através do link, descobrir todos os detalhes dessas tarefas.
É quase possível liberar, resta apenas testar minuciosamente nossas alterações. Para fazer isso, o ramo de lançamento é implantado em um ambiente próximo à produção (chamamos de estágio) e é testado após o lançamento. A implantação e os testes são montados em um pipeline no TeamCity, e nossa tarefa é iniciá-lo e aguardar, cruzando os dedos, para que os testes funcionem bem. O bot lança um pipeline durante o início da regressão.
Deixe-me lembrá-lo de que começamos com o fato de que tudo isso foi feito manualmente. Fechando os punhos, Relizmen ativou links e ferramentas: TeamCity, Kaiten, Slack, Github e isso não é tudo! E agora temos todo um conjunto de ações a partir das quais a primeira equipe do bot já está formada. O lançador digita “/ startregress” e, recostando-se na cadeira, observa o nosso bot:
- cria um canal no messenger
- chama lá todo mundo que você precisa
- verifica se uma solicitação pull pode ser criada
- cria uma solicitação pull e preenche sua descrição
- cria uma coluna de liberação em um quadro eletrônico e move os cartões de tarefas para lá
- lança um pipeline que libera a ramificação de liberação para o ambiente e executa testes lá
Analisamos todo o processo de lançamento e anotamos quanto tempo cada estágio do lançamento leva. Isso dá ao desenvolvimento e aos negócios uma compreensão de quanto tempo é desperdiçado e o que nos impede de fornecer novos recursos aos usuários. Estamos sentados por dois dias e não podemos executar os testes ?! Portanto, algo está errado com nossos testes. Você precisa dar mais tempo e atenção. Anteriormente, realizando as ações de nossa lista de verificação, visitamos o Planilhas Google pelo menos cinco vezes. Cada vez que você digita uma data lá e define a hora.
Ok Google, nós automatizaremos você também! Para trabalhar com tabelas de maneira fácil e sem esforço, conectamos o pacote de pepitas Google.Apis.Sheets.v4 ao projeto de nosso bot. E então tudo acontece de maneira semelhante com outros serviços de acordo com o esquema: enviamos uma solicitação na qual dizemos qual valor inserir em qual célula. Esta consulta tem a seguinte aparência:
public void InsertEntry(string cellAddress, string value) {
Depois de configurar a integração com o Google, preparamos o segundo comando do nosso bot "/ update" e é isso que ele faz:
- adiciona uma string vazia para inserir valores nela
- vai para o GitHub, olha quando eles criaram o ramo de lançamento e adicionam a data de sua criação ao tablet
- do TeamCity coleta dados no primeiro início do pipeline e informações sobre quando o pipeline foi concluído com êxito
O próximo passo é o lançador lançar o lançamento. Agora o cálculo é feito manualmente. Tendo estabelecido um país, observamos como o lançamento se comporta na batalha. Depois de garantir que tudo esteja bem, de acordo com os registros e ferramentas de monitoramento de Kibana e Grafana, publicamos o próximo país. Esse processo não é tão fácil de automatizar. Mas aqui há algo a melhorar, embora não com a ajuda de um bot. Por exemplo, antes, sempre que perguntávamos à equipe de infraestrutura se era possível liberar. Porque, quando íamos fazer isso, outro trabalho poderia ocorrer em nossos servidores e nosso lançamento seria inapropriado.
Reunimos uma reunião para otimizar o processo de lançamento. Uma das soluções foi que agora o lançador simplesmente analisa o status em um dos canais do Slack, onde a infraestrutura envia permissão para decolar. Isso é mais conveniente do que perguntar constantemente a mesma coisa e, em 90% dos casos, obter a resposta "Você pode".
Por alguma razão, essas coisas aparentemente elementares não vieram imediatamente à mente. Agradecimentos especiais devem ser dados aos novos desenvolvedores da empresa. Tendo vindo a nós, mais cedo ou mais tarde eles se tornaram relismens. Para os caras que trabalharam conosco por um longo tempo, o processo não parecia ser algo complicado, mas algo familiar. Novos membros da equipe voltaram nossa atenção para os pontos de crescimento e participaram ativamente da organização do trabalho sobre melhorias.
Enquanto isso, chegamos ao último estágio. Nosso liner de lançamento chegou, apenas uma equipe “/ release-complete” nos separa do final. O que ela faz:
- mesclar solicitação de recebimento com liberação para ramificação principal
- remove o ramo de lançamento
- cria descrição da versão no github
- canal de lançamento de arquivos no Slack
- move os cartões no Kaiten da coluna "release -..." para a coluna "Done" e exclui a coluna de liberação
- passa o bastão, convidando para liberar o próximo comando
Para resumir, gostaria que você se perguntasse: você tem processos rotineiros e chatos? Você ainda está fazendo isso com as mãos? O que impede você de acabar com isso de uma vez por todas? Reúna uma reunião, analise os processos, jogue fora tudo o que você não precisa e isso se tornou um ritual. Ao automatizar tudo o que você precisa, você começará a ter a alegria do que machucou antes e a economizar ao acelerar a liberação ou qualquer outro processo.