Embora Tekton sirva para rodar o próprio CI no Kubernetes, os conceitos aqui apresentados podem ajudar a *entender melhor* de sistemas CI/CD no geral, inclusive os que trabalhamos no dia-dia, tais como Github, Gitlab, CircleCI etc
+
O primeiro foi uma introdução aos 3 principais componentes do Tekton: Step, Task e Pipeline.
São peças importantes que têm sua lógica fundamentada em diversos outros sistemas de CI/CD.
Depois, melhoramos nossa pipeline de modo que não seja mais ativada manualmente, mas sim através de um Webhook que é chamado por um evento de PR/Push do Github.
Pipeline sem entrega não vale de nada, aqui vemos como fazer a entrega contínua da aplicacão em produção, utilizando Tasks já criadas pela própria comunidade.
No intuito de montar uma pipeline mais robusta com ambiente de Staging e Produção, introduzimos o conceito de Interceptors que permitem mainpular os payloads que chegam no Webhook.
E pra quem quer entender melhor sobre o que é CI/CD no geral sem estar amarrado a tecnologia, escrevi também esse artigo para explicar de forma genérica estes conceitos.
Ao meu ver, permite padronizar o ciclo de CI/CD utilizando a mesma infra-estrutura.
Pode no fim ajudar a reduzir custos e aumentar eficiência, pois temos mais controle da ferramenta, o que também ajuda no troubeshooting e debugging.
FAQ
"Ah mas dá pra fazer isso com Gitlab também"
Sim, mas Gitlab te deixa amarrado com a estrutura deles. Utilizando algo feito em cloud-native e que faz parte da CD Foundation, garante uma certa longevidade e padronização da ferramenta.
FAQ
"E se meu cluster cair?"
Se o cluster cair, caiu tudo né, CI/CD fora pode nem ser o maior dos problemas nesse caso em específico.
FAQ
"Mas isso não traz mais custos pro cluster, pois tem que provisionar mais nós etc?"
Depende. O custo de provisionar eventualmente um nó por conta de pods que rodam tasks de CI pode ser muito baixo se comparado com o que as vezes se paga para Github e afins.
FAQ
"Você tá advogando pelo Tekton, mas cada um tem seu contexto"
Sim, to advogando pq é um conceito que acredito ser válido para muitos projetos. Se no teu não serve, faz parte.
Tekton não serve para tudo, como tudo na vida não serve pra tudo.
No fim, uma imagem de resumo de como seria uma arquitetura nestes moldes
• • •
Missing some Tweet in this thread? You can try to
force a refresh
Num cenário primitivo sem concorrência, os programas ficam em fila à espera para que possam utilizar os recursos físicos.
Um programa de cada vez.
Aqui, não há qualquer tipo de race condition, era assim que se desenvolvia programas nos anos 40.
Ociosidade da CPU
O problema deste modelo primitivo é que, quando o programa fica à espera de I/O (impressora, tela, etc), a CPU fica ociosa, causando assim um desperdício de recursos físicos.
Primeiramente, como devemos testar um componente de software?
Eu começo dizendo que o teste de um componente é uma forma de refutar seus comportamentos, independente de quais sejam.
+
Teste refutado (fail)
Neste caso, há a presença de um bug. É necessário então implementar código para que o teste deixe de ser refutado e que aquele bug em específico possa ser solucionado.
não to lembrado ou não conheço um guia oficial de linguagem de programação que tenha feito uma explicação tão sólida e clara sobre Stack e Heap como o guia de Rust
ultimamente to numa de impulsionar conteúdo bom, então vou deixar na thread links de blogs (dos que acompanho no dev.to) de pessoas que eu sigo por lá.
quem tiver links pra compartilhar, manda aqui também 💪