Github Actions — O que achei?
Olá amigos! Tudo bem? Resolvi fazer uma postagem que possa ser útil quando se estiver procurando ferramentas de automação de Continuous Integration e Continuous Delivery. Não entrarei nas definições de CI/CD aqui, apenas abordarei acerca da ferramenta. Sem mais delongas, vamos!
Sobre
O Github actions é uma ferramenta que cria workflows de CI/CD para sua aplicação, dado alguns eventos do repositório e está intimamente contectado com o Github. Se você trabalha com software livre ou não, o mesmo funciona igualmente para os dois casos, sendo que ao lidar com software fechado o mesmo possui alguns limites de tempo de utilização. Se você for usuário da versão free do github, você tem direito a 2000min de build/mes, enquanto na assinatura PRO você possui direito a 3000min mes.
Vantagens
Tentarei elencar algumas vantagens segundo meu ponto de vista. Com certeza há mais cenários a se explorar, mas irei me ater ao que eu testei de fato.
Bom suporte a containers
É fundamental, quando se desenvolve e testa software, possuir liberdade para configurar o ambiente onde essa aplicação será construída e testada. O Docker, enquanto sistema de virtualização a de aplicação, possui essa excelente característica. O GH Actions me agradou bastante ao possuir uma forma facilitada de se usar containers com o padrão de projeto chamado “sidecar”. Em poucas palavras, seria conectar containers que oferecem serviços ao projeto principal, como o que o mysql faria, por exemplo, com um container com um serviço WEB.
Nesse ponto eu gostei bastante, pois foi apenas determinar o serviço, assim como a imagem a ser utilizada e pronto: cá estava com um projeto possível de ser construído.
Matriz de desenvolvimento
O Github actions provém uma ótima forma de se executar um projeto, oferecendo suporte a construção do seu projeto em várias tecnologias e ou sistemas operacionais diferentes, tudo sendo configurado nos arquivos de configuração, providos em formato Yaml.
Geração de artefatos
A cada build você poderia coletar o resultado do seu projeto e transformar em um entregável, facilmente. Por exemplo, ao se trabalhar em um projeto angular, você poderia realizar um build, pegar o conteúdo da pasta dist e gerar um deployable. Ponto para o GH Actions.
Manipulação de variáveis protegidas
Ao se realiar um build, em alguns momentos se faz necessário a utilização de valores em variáveis que devem ser protegidos do usuário que consome esses serviços, assim como do usuário que desenvolve o serviço. Para isso, o git criou um repositório de chaves/valores onde se pode guardar, de maneira segura, variáveis que poderão ser utilizadas nas aplicações.
Flows customizados
Existe um repositório com vários desses flows customizados que podem ser reutilizados de maneira muito fácil, graças a padronização das suas chamadas. A saber, existe um site curou uma lista dos melhores fluxos e tutoriais que indico aqui; vai deste o arquivamento de artefatos ao envio de mensagens no telegram: https://github.com/sdras/awesome-actions
Interface leve e enxuta
O fato de não possuir elementos gráficos que poluam a interface é ótimo pois torna a interface mais fluida, atendendo o propósito de informar, de maneira efetiva e clara, o status da build do projeto.
A medida que eu for descobrindo mais coisas, certamente irei adicionando aqui. Agora vamos às desvantagens;
Desvantagens
O desenvolvimento de aplicações no github actions ainda se encontra em condição de constante evolução. Felizmente há uma comunidade bastante ativa e uma série de discussões acerca do projeto está guiando o rumo do desenvolvimento, que se mantém acelerado.
Para um usuário do Jenkins, como eu, o Github actions ainda possui uma série de lacunas a serem preenchidas.
Falta de uma documentação clara
Apesar de existir uma forte iniciativa em criar uma documentação extensiva, senti uma certa dificuldade a encontrar exemplos práticos da utilização do projeto. Um ponto que eu gostaria de frisar é a utilização dos condicionais dentro das tarefas: como saberei quais são os valores possíveis de colocar em tais condições para que meu objetivo seja atendido?
Ao pesquisar o termo no google, pelo fato do projeto ser relativamente novo, não encontro documentação tão facilmente.
Builds parametrizados
Esse é um ponto onde o Jenkins faz uma certa falta; a incapacidade de se criar builds parametrizados faz com que o processo fique mais engessado e dependente, quase que unicamente, dos processo de push; vale mencionar também que não há a opção de eu iniciar um build novo, a não ser que o mesmo tenha falhado. (É até compreensível para que não se execute um build já ok, uma vez que se consome tempo. Mas, de toda forma, seria honesto que houvesse tais controles)
Limpeza de recursos de espaço utilizado
Um ponto grave do GH actions, ao meu ver, é a incapacidade de se limpar os artefatos gerados por meio do processo de arquivamento de artefato do projeto. Você até possui o poder de apagar o registro, mas isto tem que ser feito de maneira manual, pela interface gráfica, o que não faz o menor sentido.
Felizmente você ainda pode solicitar para que a exclusão seja feita de maneira manual, via ticket. (Referindo-me se você quiser usar o GH actions para construir imagem de containers e utilizar isto na própria página de releases do mesmo)
Também não é possível configurar apenas uma certa quantidade de registros de histórico.
Conclusões
A utilização do Github actions, ao meu ver, soa bastante promissora. Uma ferramenta tudo em um, nesse aspecto, soa muito bem vinda devido a sua capacidade de integração íntima com o Github. Seus problemas surgirão com mais força conforme se utiliza da plataforma.
Como um grande ponto forte está o fato de você começar a utilizá-lo sem um gasto de recursos financeiros, mas sob um grande custo caso não otimize suas pipelines para serem econômicas.
A parte boa nesse último ponto é que eu agora passei a usar mais o Alpine para montar meus containers. rs
No mais, digam-me: já usaram? Discordam de mim? Por favor, faça-me saber. Terei o maior prazer de fomentar essa discussão. No mais espero que este texto tenha sido útil. Nos vemos numa próxima!
