BT

Disseminando conhecimento e inovação em desenvolvimento de software corporativo.

Contribuir

Tópicos

Escolha a região

Início Artigos Desenvolvimento na nuvem - do sonho à realidade.

Desenvolvimento na nuvem - do sonho à realidade.

Favoritos

Pontos Principais

  • Configurar e manter ambientes de desenvolvimento consistentes não agrega valor ao negócio. Pode ser uma tarefa demorada e muitas vezes mundana, com a qual os desenvolvedores não deveriam se preocupar.

  • Pessoas físicas e empresas tiram vantagem das ofertas de plataformas na nuvem e SaaS na maior parte do ciclo de vida de desenvolvimento de software, exceto para Desenvolvimento / Implementação / Codificação.

  • O Eclipse Theia é uma plataforma extensível para desenvolver Cloud & Desktop IDEs em várias linguagens usadas pelo Google, Eclipse Che, e Gitpod para fornecer ambientes de desenvolvimento baseados na nuvem.

  • Imagine que começar um projeto fosse tão simples quanto abrir uma URL no seu navegador - isso não é mais um sonho, tornou-se realidade.

 

 

Passei quase dois anos desenvolvendo software em um Chromebook. 16 GB de RAM, uma unidade de disco de 512 GB, ChromeOS, um monitor de tela ampla, e uma conexão à Internet. Foi a época mais produtiva da minha carreira. Deixe-me levá-lo em uma jornada, desde os dias em que os computadores eram terminais para acessar o poder da computação em servidores compartilhados, até os tempos em que o poder da computação mudou para desktops / laptops, e todo o caminho (de volta?) até meu fluxo de trabalho atual, onde os laptops são uma fina camada para fazer interface com o poder da computação em servidores compartilhados novamente - também conhecido como 'na nuvem'.

Papel, quadro branco, reuniões presenciais, e servidores internos

Uma representação do ciclo de vida de desenvolvimento de software (CVDS) contém os seguintes cinco estágios:

5- Estágio CVDS

Há pouco tempo atrás, coletávamos os requisitos pessoalmente e no papel, projetávamos em quadros brancos, desenvolvíamos e testávamos o código fonte em computadores desktop e implantávamos em servidores internos onde operávamos e mantínhamos as aplicações. O que parece tempos antigos, no meu caso, realmente foi há apenas duas décadas; para outros, muito disso ainda se aplica hoje.

Trabalhávamos nas etapas do CVDS off-line e no escritório. O passo mais "moderno" foi indiscutivelmente a "Implementação", onde os desenvolvedores usaram seus computadores como terminais para acessar as primeiras versões da World Wide Web, ajudando-os a encontrar respostas para problemas, escrever software, ou participar de canais do IRC com indivíduos com ideias semelhantes.

Implementação - O desafio inicial

Como parte do estágio de implementação, cada desenvolvedor segue instruções (documentadas) para configurar seu ambiente de desenvolvimento pessoal. As instruções são parecidas com estas:

  1. Instale o editor X, adicione os plugins Y e Z
  2. Baixe o código fonte
  3. Instale SDKs e dependências de linguagem necessários
  4. Compile e execute o software localmente

O desenvolvimento de software é uma profissão dinâmica. O código fonte muda diariamente, e de vez em quando muda-se a maneira como o ambiente de desenvolvimento local precisa ser configurado.

Para os membros da equipe existentes, as mudanças no ambiente de desenvolvimento são incrementais. Instale um novo plugin, atualize para a versão mais recente de uma dependência, ou execute um script temporário. Se a sua experiência for parecida com a minha, a instrução interna "Dia 1: Configuração do desenvolvimento" tende a ser esquecida, o que, ao que parece, não afeta ninguém. A mudança incremental é comunicada ad-hoc durante uma reunião diária ou por meio de uma plataforma de mensagens instantâneas.

Mas então, tem a Hanna. Recentemente, ela aceitou entrar para a equipe, e está animada para seu primeiro dia e ansiosa para começar a trabalhar rapidamente. Ela abre a instrução interna do "Dia 1: Configuração de desenvolvimento" e segue em frente, agradecida pela equipe ter documentado essas etapas. Exceto que, a etapa 8... não funciona. Um membro da equipe a ajuda, eles consertam e seguem em frente. O padrão se repete durante todo o processo restante. O tempo passa e o primeiro dia termina com menos emoção do que começou.

Para a nuvem nós migramos

Graças à Internet, as soluções de software como serviço rapidamente trouxeram uma mudança significativa na rotina diária de uma equipe de software. O que costumava ser feito manualmente e off-line agora pode ser executado de forma mais eficiente online, com colaboração em tempo real e ciclos rápidos de feedback.

Hoje em dia, é comum que as etapas de requisitos, projeto, teste, e manutenção do CVDS sejam realizadas na nuvem. Quer uma empresa migre para a nuvem ou nasça na nuvem, um negócio denominado nativo da nuvem, a tendência é clara: a nuvem veio para ficar e o CVDS também adota essa inovação. Exceto para a fase de implementação.

O que aconteceu com "Implementação"?

Vamos dar uma olhada no CVDS novamente. Desta vez, destacamos quais etapas são realizadas na nuvem e quais (ainda) não são.

Para todas as etapas, exceto a implementação, usamos um navegador como terminal para acessar o software na nuvem. O que antes era o estágio em que estávamos bastante à frente da curva foi deixado para trás, enquanto todos os outros estágios inovaram e continuam a fazê-lo. Equipes de desenvolvimento em todo o mundo até hoje usam hardware poderoso e frequentemente caro para escrever e compilar código fonte, apenas para colocá-lo imediatamente na nuvem. Sem mencionar a necessidade de atualizar esse hardware a cada poucos anos.

Com a computação em nuvem na vanguarda de tantos setores, processos, e nossa vida diária, é hora de fazer uma pergunta importante:

O que aconteceu com a fase de implementação?

Duas perguntas relacionadas e igualmente importantes são:

  • Por que ainda precisamos de laptops poderosos para escrever software?
  • O que torna tão difícil mover esse estágio para a nuvem?

Em primeiro lugar, a razão para o estágio de implementação ser tão demorado é devido à falta de soluções disponíveis que sejam facilmente adotáveis. Soluções como Cloud9, servidor de código, e possivelmente outras existem, mas não parecem amplamente utilizadas.

Conheça o Eclipse Theia e o Gitpod

Finalmente, com Eclipse Theia, temos uma "plataforma de código aberto para desenvolver Cloud / Desktop IDEs multilíngues com tecnologias da web de última geração". Theia já é usado pelo Google Cloud, Eclipse Che, e Gitpod.

Quero me concentrar no Gitpod como um serviço hospedado. Isso me permitiu transformar completamente a maneira como desenvolvo software. Como usuário de um Chromebook, a maioria das minhas tarefas diárias já acontece na nuvem e por um tempo sonhei com o dia em que não precisaria mais de aplicativos instalados localmente! Embora os Chromebooks ofereçam suporte a aplicativos Linux e me permitam usar o VS Code, até alguns meses atrás ele ainda exigia que eu instalasse e mantivesse o software localmente.

Com Gitpod em mente, deixe-me reescrever sua instrução interna do dia 1: Setup para desenvolvimento: Primeira e última etapa: Click gitpod.io/#https://github.com/your-org/your-repository

Na verdade, remova aquela instrução interna e adicione esse link ao README.md do projeto - mantenha a documentação próxima ao seu código-fonte.

Um clique nesse link é o suficiente para iniciar o workspace de desenvolvimento. Lembra da Hanna? Sua experiência de integração agora é feliz e verdadeiramente emocionante. Novos membros da equipe estão prontos para contribuir em minutos, não dias!

Com o arquivo de configuração .gitpod.yml colocado na raiz do seu projeto, você obtém acesso a uma ampla gama de recursos adicionais descritos abaixo.

Consistência com imagens Docker

Se o seu projeto requer ferramentas de terceiros ou outras personalizações, você pode fornecer uma imagem Docker personalizada. Depois de configurado para um projeto, cada nova estação de trabalho é baseada nessa imagem, e todas as alterações nessa imagem são aplicadas na próxima vez que um membro da equipe abrir a estação de trabalho. Como um benefício adicional, todas as mudanças nesta imagem Docker tornam-se parte do seu histórico de controle de versão. Não há mais incerteza sobre o que mudou, quando, e por quem.

Estações de trabalho pré-configuradas

Imagine que seu colega designa você como revisor de um pull request. Com as pré-configurações habilitadas, o Gitpod prepara automaticamente a estação de trabalho (baixa o código do PR, instala as dependências) para que, no momento em que você abrir o pull request na estação de trabalho, ele esteja pronto para revisar e testar.

Revisões de código integradas

Você já olhou para um pull request e disse para si mesmo "Isso parece bom" e deixou um comentário "Parece bom", sem realmente testar o código? Provavelmente sim, todos nós já o fizemos. O Gitpod vem com um recurso de revisão de código integrado que permite revisar as alterações e deixar comentários embutidos. Para uma produtividade ainda melhor, você pode configurar o Gitpod para adicionar um comentário no PR com um link para uma estação de trabalho que contém as exatas alterações de código desse pull request.

Seu fluxo de trabalho como revisor agora é: aba o PR; clique no link; revise e testE o código.

Espaços de trabalho paralelos e compartilhados

Um favorito pessoal, os espaços de trabalho paralelos me permitem revisar o código sem interromper minhas próprias alterações de desenvolvimento. Não há mais mensagens de confirmação como "WIP: confirmação temporária.", ou stashing para alterar um branch para uma sessão de programação em par com alguém. Basta abrir uma nova estação de trabalho em uma guia diferente do navegador, compartilhar a estação com o colega, e trabalhar em pares - mesmo remotamente. Quando terminar, feche a guia do navegador e você estará de volta em sua área de trabalho com seu trabalho.

Suporte para extensões do VS Code

Por último, para qualquer usuário do VS Code, você pode instalar suas extensões favoritas e elas serão aplicadas automaticamente a todos as estações de trabalho em que você trabalhar. Não importa mais se você trabalha em seu laptop ou em qualquer outro lugar, suas extensões estarão disponíveis assim que você acessar o Gitpod com sua conta.

Você recomenda que todos os membros da equipe usem certas extensões para torná-los mais produtivos? Configure essas extensões em um nível de projeto e qualquer pessoa que trabalhe nesse projeto terá as extensões disponíveis automaticamente.

Como começar

Tudo o que é necessário é uma URL do repositório. Para isso, crie um novo repositório no GitHub ou GitLab e certifique-se de inicializar o repositório com um README. Alternativamente, sinta-se à vontade para usar um repositório existente!

Para iniciar o ambiente Gitpod para o novo repositório:

  1. Copie a URL do repositório. Você pode usar esta URL se não tiver uma disponível.
  2. Abra uma nova guia do navegador.
  3. Digite "gitpod.io/#" no campo URL e acrescente "https://seu-repositório-url".
  1. Clique em Login with GitHub / Launch Workspace.
  2. Quando solicitado, autorize o Gitpod a acessar sua conta GitHub ou GitLab.
    • Não há necessidade de um novo nome de usuário e senha no Gitpod.
  1. Aceite os termos de serviço do Gitpod e clique em Create Free Account.

Em alguns segundos, seu ambiente Gitpod está instalado e funcionando.

Configuração do projeto no Gitpod

Uma notificação oferece definir a configuração do Gitpod.

Clique em Setup Project. Isso inicia um assistente de configuração que o orienta pelo processo.

Passo 1: Crie .gitpod.yml

Clique em Create .gitpod.yml para definir um arquivo de configuração básico.

Passo 2: Alterar a imagem base

É aqui que você pode selecionar uma imagem base diferente, por exemplo, com MySQL instalado. Alternativamente, você pode escolher uma imagem personalizada, especificamente para as necessidades de seu negócio e projeto.

Passo 3: Atualizar o arquivo Readme

Clique em Update Readme para adicionar um símbolo do Gitpod. Com isso, qualquer pessoa que trabalhe no projeto pode iniciar o ambiente Gitpod com um único clique no símbolo.

Passo 4: Configuração de test drive

Nota: Se você usou a URL do meu repositório, será solicitado que você crie um fork do projeto porque você não é um colaborador. Se você usa um projeto próprio, pode fazer push sem a necessidade do fork.

Clique em Push to Branch / Start Workspace. O Gitpod pedirá permissão para fazer push no branch. Clique em Grant Permissions e, na nova janela, clique em Authorize gitpod-io. Clique em OK para fechar a caixa de diálogo de permissões atualizadas e feche a guia do navegador.

Siga as instruções para fazer push das alterações de código e rastrear o branch como um branch upstream.

Passo 5: Criar um pull request

Nesta etapa final, o Gitpod fornece uma interface para criar um pull request que contém a configuração do Gitpod. Clique em Create pull request para criar o PR.

Para ver como é a configuração mais básica, dê uma olhada aqui.

Revisão de código

Assim que o pull request for aberta, qualquer um na equipe pode revisá-lo:

  1. Navegue até o pull request em seu navegador.
  2. Copie a URL do pull request.
  3. Digite "gitpod.io/#" no campo URL e acrescente "https://your-pull-request-url".

Logo depois disso, o Gitpod está instalado e funcionando com o código do pull request, pronto para ser revisado, testado, e mesclado.

O revisor pode deixar comentários de dentro do ambiente de desenvolvimento:

Desenvolvimento baseado em nuvem daqui para frente

Assim que o pull request de configuração do Gitpod for mesclado, qualquer pessoa que trabalhe no projeto pode clicar no símbolo Gitpod - Ready-to-code no README do projeto e começar a desenvolver alguns segundos depois.

Conclusão

O Eclipse Theia lançou recentemente a versão 1.0 de sua plataforma Cloud / Desktop IDE. Isso marca uma grande mudança no que considero o último estágio remanescente do ciclo de vida de desenvolvimento de software para migrar totalmente para a nuvem - o estágio de implementação.

Espero que a cultura de trabalhar em casa se torne mais importante para as empresas em todo o mundo, que buscam os melhores talentos, um talento que não necessariamente vive perto de seus escritórios. Com o Eclipse Theia e uma versão hospedada dele no Gitpod.io, estamos um grande passo mais perto de uma experiência de desenvolvimento ponta a ponta completa na nuvem.

Agora que o processo de introdução é tão conciso quanto um único clique, você pode pensar sobre a próxima etapa da eficiência: o que falta melhorar em seu projeto para que os novos membros da equipe possam liberar sua primeira contribuição para a produção antes de voltarem para casa no final do primeiro dia de trabalho?

Sobre o autor

Mike Nikles é um arquiteto de software que valoriza a produtividade e o moral da equipe. Seu foco está em soluções escaláveis nativas da nuvem, principalmente baseadas em JavaScript / Typescript implantado no Google Cloud Platform. Por duas décadas, Mike tem implementado ideias desde a fase de concepção até a implantação, em startups ou como líder de equipes em empresas maiores. Encontre o Mike no Twitter, LinkedIn, ou em www.mikenikles.com. Atualmente, ele trabalha com clientes de viagens empresariais no Reino Unido e Irlanda como parte de sua função no Google Cloud.

Avalie esse artigo

Relevância
Estilo/Redação

Conteúdo educacional

BT