Ferramentas de desenvolvimento: 17 segundos reduzidos em uma construção e uma multidão enlouqueceu

As coisas que entusiasmam as pessoas no negócio de software fariam a maioria das pessoas coçar a cabeça, confusas. Eventos aparentemente aleatórios, como o anúncio de janelas de suporte estendidas para software empresarial essencial no Red Hat Summit 2024, me fizeram relembrar a comemoração mais alta que já ouvi em uma conferência de desenvolvedores.

Anos atrás, eu era jornalista e apresentador da extinta Android Developer Conference (AnDevCon). Subi ao palco principal e apresentei todos os palestrantes principais. Contei piadas e anedotas nerds, é claro, mas não posso afirmar que tenha encantado a multidão. Os vários palestrantes que apresentaram palestras técnicas no evento definitivamente fizeram isso, mas eu não.

Mesmo assim, nenhum dos apresentadores regulares causou alvoroço. Essa honra foi reservada ao pessoal do Google e da JetBrains, que, em sua palestra na hora do almoço, anunciaram que o então neófito Android Developer Studio conseguiu reduzir 17 segundos de cada compilação.

A multidão enlouqueceu. As pessoas jogavam pratos de papel para o alto, gritando e gritando como cowboys bêbados, comemorando como se seu time tivesse vencido a Copa da Inglaterra. Assobios, vaias e aplausos aumentaram como se uma banda famosa tivesse acabado de subir ao palco. Um cara correu até a frente da sala, cumprimentou o palestrante e correu de volta para sua cadeira.

Desenvolvedores de ferramentas, não apenas ferramentas de desenvolvedor

Conto essa história para gerentes de desenvolvimento de software o tempo todo. O que quero dizer não é que os desenvolvedores fiquem entusiasmados com 17 segundos. É o que os gerentes e fabricantes de ferramentas geralmente não fazem. Eles deviam.

Eles deveriam se preocupar com essa economia de tempo porque é muito mais do que a economia real de tempo por construção. Embora agregada em dezenas de compilações diárias e centenas de desenvolvedores, a economia de tempo é significativa. A maior economia, aqui, é mental. Isto é uma questão de sanidade. Trata-se de minimizar o tédio. Trata-se de ferramentas de qualidade nas mãos de desenvolvedores de qualidade que lançam software de qualidade. Trata-se de automatizar as coisas chatas.

Essa economia de 17 segundos para desenvolvedores Android é um exemplo de para onde se dirigiam as mentes dos fabricantes de ferramentas quando estavam criando um ambiente para outros desenvolvedores. É uma mentalidade de recursão e metapensamento sem fim: como podemos melhorar nossa própria experiência de desenvolvimento de software com o software que estamos escrevendo?

No passado, os desenvolvedores de jogos tinham um ditado: para fazer um jogo, você deve primeiro criar as ferramentas para fazê-lo. Hoje, isso é muito menos verdadeiro graças aos ambientes de desenvolvimento e motores de jogos compartilhados.

Para o desenvolvedor de software empresarial moderno, esse ditado ainda é válido, mas com uma tendência um pouco diferente, focada na nuvem: para fazer um negócio, você deve primeiro criar os serviços sobre os quais o negócio será construído. Ou pelo menos conecte-os de alguma forma.

Em ambos os casos, jogos e empresas, o trabalho diário de construir esses ativos, testá-los, rotular problemas e compilações e bugs e recursos… Todo esse trabalho precisa ser automatizado, ou então alguém vai queimar fora.

E, uma vez automatizados, os pipelines de construção precisam ser otimizados. Eles devem ser produzidos dentro da organização. Suas equipes de DevOps e de capacitação de desenvolvedores devem ser capazes de ficar na frente de suas equipes e dizer “Reduzimos 17 segundos em cada construção”.

As ferramentas que governam

Infelizmente, construir um ótimo fluxo de trabalho e pipeline para seus desenvolvedores não envolve apenas construções mais rápidas. No moderno ambiente de nuvem híbrida, isso significa unir muitos serviços, o que significa, em primeiro lugar, estabelecer serviços. Naturalmente, aproveitar o código aberto ajuda a limitar a quantidade desse pipeline que você terá que reinventar.

Existem muitos projetos de código aberto que podem ajudá-lo a construir e otimizar seu pipeline de desenvolvimento de software para entrega em nuvem híbrida. Aqui estão alguns links para projetos e conteúdos que irão ajudá-lo.

• Podman: Podman é um mecanismo de gerenciamento de contêineres, pods e imagens de contêineres de código aberto. Crie, inicie, inspecione e gerencie pods. Jogue Kubernetes YAML diretamente com Podman, gere Kubernetes YAML a partir de pods e implante em ambientes Kubernetes existentes.
• Tekton: Tekton é uma estrutura de código aberto poderosa e flexível para a criação de sistemas CI/CD, permitindo que os desenvolvedores construam, testem e implementem em provedores de nuvem e sistemas locais. Disponível comercialmente em OpenShift Pipelines.
• Stackrox: A plataforma de segurança StackRox Kubernetes realiza uma análise de risco do ambiente de contêiner, fornece visibilidade e alertas de tempo de execução e fornece recomendações para melhorar proativamente a segurança, fortalecendo o ambiente. StackRox se integra a todos os estágios do ciclo de vida do contêiner: construção, implantação e tempo de execução. Disponível comercialmente como Red Hat Advanced Cluster Security for Kubernetes.
• Quay: Quay constrói, analisa e distribui suas imagens de contêiner. Ele pode automatizar a construção de contêineres, com integração ao GitHub, Bitbucket e muito mais. As contas do Robot permitem bloquear o acesso automatizado e auditar cada implantação.
• Argo CD: As definições, configurações e ambientes de aplicativos devem ser declarativos e controlados por versão. O Argo CD tem como objetivo tornar a implantação de aplicativos e o gerenciamento do ciclo de vida automatizados, auditáveis ​​e fáceis de entender.
• KubeVirt: Virtualização dentro do Kubernetes. As equipes que dependem de cargas de trabalho existentes baseadas em máquinas virtuais têm autonomia para colocar aplicativos em contêineres rapidamente. Com cargas de trabalho virtualizadas colocadas diretamente em fluxos de trabalho de desenvolvimento, as equipes podem decompô-las ao longo do tempo enquanto ainda usam os componentes virtualizados restantes. Disponível comercialmente como OpenShift Virtualization.
• Konveyor: A comunidade Konveyor ajuda a modernizar aplicativos, fornecendo ferramentas de código aberto para rehospedar, replataformar e refatorar aplicativos para Kubernetes e tecnologias nativas da nuvem.
• Quarkus: uma pilha Java nativa do Kubernetes adaptada para OpenJDK HotSpot e GraalVM, criada a partir das melhores bibliotecas e padrões Java. Java subatômico supersônico.
• Red Hat OpenShift: a plataforma de aplicativos corporativos confiável, abrangente e consistente, construída em código aberto e projetada para uso empresarial em escala, combinada em nuvens públicas e privadas. Inclui todos os itens acima com suporte comercial.

Uma vez liberado, seus desenvolvedores podem realizar o trabalho de maneiras que você não esperava. Às vezes, são necessárias apenas algumas etapas simples, como combinar o fluxo de dados em um único fluxo para que os desenvolvedores não precisem ler os problemas em três locais diferentes. Outras vezes, pode levar meses para configurar ações complexas e automação de implantação para fornecer ambientes de produção compatíveis que possam ser replicados em vários locais. Seus desenvolvedores provavelmente já sabem o que é ruim. Pergunte a eles!

Quaisquer que sejam suas necessidades, cada vez que você adiciona novos recursos e otimizações ao seu pipeline de desenvolvimento, você tem a chance de encantar seus desenvolvedores. E é muito mais provável que um desenvolvedor satisfeito resolva aquele complicado projeto de modernização de aplicativos que ninguém quer tocar.

A postagem Ferramentas de desenvolvimento: 17 segundos eliminados de uma construção e uma multidão enlouqueceu apareceu pela primeira vez em The New Stack.