Esta página foi traduzida pela API Cloud Translation.

Análise detalhada da CLI do Gemini

1. Introdução

Olá, Meu nome é Faísca! Que bom que você pôde vir. Eu vim de um cluster do GKE em us-central1 para estar aqui hoje. Este é um codelab.

Passei a vida toda correndo pelos fluxos de dados do Google Cloud e já vi de tudo. Vi vocês, arquitetos e engenheiros, construindo coisas incríveis. Mas também já vi você ficar preso nos arbustos. Você sabe do que estou falando! Essa sensação de troca de contexto ao depurar um pod no GKE. Você está alternando entre kubectl logs, o console do GCP para verificar a integridade do nó, o ambiente de desenvolvimento integrado para analisar o código-fonte implantado e uma guia do navegador com a documentação oficial do Kubernetes para hooks de ciclo de vida do pod. Cada salto é uma quebra de foco.

E as ferramentas complexas! gcloud, kubectl, terraform... cada um com sua própria DSL e uma montanha de flags. Isso leva a uma busca constante por documentação. Você acaba pesquisando o comando gcloud perfeito com a combinação certa de flags --filter e --format para receber os dados necessários. É como tentar encontrar uma noz específica em uma floresta de milhões. E nem me fale das tarefas repetitivas. Já vi você escrever o mesmo Dockerfile e cloudbuild.yaml para um novo serviço do Python tantas vezes que o código provavelmente tem déjà vu.

Estou aqui para mostrar uma maneira melhor. Um caminho secreto pela floresta. É para isso que serve a CLI do Gemini!

O que é a CLI do Gemini?

Então, qual é esse atalho mágico que me deixa tão animado?

Pense na CLI do Gemini como seu companheiro pessoal na nuvem, direto no terminal. É uma conversa, uma parceria! Ele é sensível ao contexto, ou seja, não apenas ouve, mas entende. Ele pode ler seus arquivos, aprender as convenções do seu projeto (como o uso de tabulações ou espaços) e descobrir o que você está tentando fazer. É como se eu pudesse sentir o cheiro das bolotas que você está tentando juntar!

Arquitetura de alto nível (vamos dar uma olhada por dentro!)

Como tudo isso funciona? É uma mistura de algumas coisas legais que funcionam em harmonia:

Um modelo de linguagem avançado:é o cérebro! Especificamente, é um modelo multimodal grande treinado pelo Google. Multimodal significa que ele não entende apenas texto, mas também a estrutura e o significado do código. Isso permite que ele raciocine sobre seu software, e não apenas o leia.
Seu contexto local:isso é crucial. A CLI Gemini é executada como um processo na sua máquina local, com as mesmas permissões da sua conta de usuário. Isso significa que ele pode acessar seu sistema de arquivos para oferecer ajuda específica para o projeto. Não é um serviço de nuvem distante tentando adivinhar seu código, ele está aqui com você.
Um ecossistema de ferramentas:é assim que o modelo interage com o mundo. Ele tem um conjunto bem definido de funções que pode chamar, como read_file ou run_shell_command. Pense nisso como uma API segura. O modelo decide o que fazer e qual ferramenta usar. Depois, ele gera um bloco tool_code para executar a ação. Isso torna as ações dele previsíveis e confiáveis.
Execução de comandos do shell:esta é a verdadeira mágica! Ele pode executar qualquer comando em um subshell bash -c <command>. Ele captura o stdout, o stderr e o exit code. Isso é muito importante! Isso significa que a CLI do Gemini pode executar um comando, verificar se ele falhou e tentar corrigir com base na mensagem de erro.
A rede de segurança:essa é minha parte favorita! Antes da execução desse bloco tool_code, o cliente da CLI vai mostrar o comando ou código exact e pedir sua confirmação. É uma verificação do lado do cliente, então você tem a palavra final antes que qualquer coisa toque no seu sistema. Você está sempre no controle.

Não é apenas um chatbot, é um faz-tudo! Um ajudante ativo na sua aventura de programação.

O conceito principal: declarativo x imperativo

A maior e mais incrível mudança é passar de dizer ao computador como fazer algo para dizer o que você quer.

Imperativo (o caminho antigo e complicado): você precisa dar todas as etapas. Você precisa ser especialista no idioma específico do domínio da ferramenta. Como este comando monstruoso:
```
gcloud compute instances create my-vm --project=my-project --zone=us-central1-a --machine-type=e2-medium --image-family=debian-11 --image-project=debian-cloud --metadata-from-file startup-script=./startup.sh --tags=http-server,dev
```
Eita! Olha só! Você precisa conhecer a sintaxe para tipo de máquina, família de imagens, metadados e tags. Se você perder uma parte, vai receber um erro enigmático.
Declarativo (o atalho do Sparky!): Basta dizer o que você quer em inglês simples.

Create a new e2-medium VM for my web server in us-central1, run the startup.sh script, and tag it for http traffic.

Pronto! O Gemini analisa sua solicitação, mapeia para os parâmetros da ferramenta gcloud, descobre a sintaxe correta para cada flag e cria esse comando grande e assustador para você. Em seguida, ele apresenta o conteúdo para aprovação. O objetivo é permitir que você pense no panorama geral, não que decore flags da linha de comando.

Como ampliar o poder do Gemini: uma introdução às extensões da CLI

Embora a CLI do Gemini seja uma ferramenta poderosa pronta para uso, o verdadeiro potencial dela é desbloqueado com as extensões. As extensões são pacotes de comandos, ferramentas e comandos personalizados que melhoram a funcionalidade da CLI, permitindo que você a adapte às suas necessidades e fluxos de trabalho específicos.

Encontrar e instalar extensões

A CLI do Gemini tem um ecossistema crescente de extensões criadas pelo Google e por desenvolvedores terceirizados. Confira o diretório oficial de extensões em geminicli.com/extensions.

Para instalar uma extensão, use o comando gemini extensions install com o URL do repositório Git dela. Por exemplo, para instalar a extensão oficial do Cloud SQL para PostgreSQL, execute:

gemini extensions install https://github.com/gemini-cli-extensions/cloud-sql-postgresql

Chega de conversa! Vamos colocar a mão na massa e testar isso!

2. Antes de começar

Olá, futuros magos da nuvem! Sparky, ao seu dispor. Antes de começar nossa grande aventura, precisamos garantir que o ambiente do workshop esteja pronto. Pense nisso como preparar nossas malas com todas as ferramentas certas e bolotas mágicas antes de irmos para a floresta. Siga-me!

Se você já tiver um projeto do Google Cloud, use a CLI Gemini no Google Cloud Shell, já que ela vem pré-instalada. Se preferir, siga estas etapas para configurar na sua máquina local.

Etapa 1: o essencial (pré-requisitos)

Todo bom aventureiro precisa de uma base sólida. Antes de instalar a CLI do Gemini, você precisa configurar algumas coisas na sua máquina local.

SDK do Google Cloud (gcloud): é o principal conjunto de ferramentas do Google Cloud. A CLI do Gemini faz parte dessa família.

Verifique se ele está instalado: execute gcloud --version. Se um número de versão aparecer, está tudo certo.
Se não estiver instalado: siga as instruções oficiais em cloud.google.com/sdk/docs/install.

Git: necessário para clonar o repositório do laboratório prático.

Verifique se ele está instalado: execute git --version.
Se não estiver instalado: você pode fazer o download em git-scm.com/downloads.

Projeto do GCP e autenticação:

Verifique se você tem um projeto do Google Cloud com o faturamento ativado. Isso é muito importante!
Faça login na sua Conta do Google executando:

gcloud auth login

Defina o projeto para a sessão. Encontre o ID do projeto no Console do GCP e execute:

gcloud config set project YOUR_PROJECT_ID

(Substitua YOUR_PROJECT_ID pelo ID do projeto real.)

Node.js versão 20 ou mais recente

Etapa 2: faça a mágica acontecer! (Como instalar a CLI do Gemini)

Agora que já falamos do básico, vamos ao que interessa! Vamos instalar a CLI do Gemini.

Executar instantaneamente com npx

# Using npx (no installation required)
npx https://github.com/google-gemini/gemini-cli

Instalar globalmente com npm

npm install -g @google/gemini-cli

Instalar globalmente com o Homebrew (macOS/Linux)

brew install gemini-cli

Verificar a versão do Gemini

gemini --version

Você vai encontrar um número de versão. Isso confirma que a instalação foi concluída.

Etapa 3: energização (configuração)

Agora que a CLI do Gemini está instalada, precisamos dar a ela as chaves do reino. Primeiro, execute o comando gemini no terminal. Você verá a seguinte tela:

Para simplificar, você pode fazer a autenticação com sua Conta do Google, que dá acesso ao Gemini 2.5 Pro com uma janela de contexto de 1 milhão de tokens e até 60 solicitações/minuto e 1.000 solicitações/dia sem precisar gerenciar uma chave de API.

Se quiser acessar modelos específicos do Gemini ou fazer upgrade para limites mais altos quando necessário, use a chave de API do Gemini como método de autenticação.

Para equipes empresariais e cargas de trabalho de produção que já têm um projeto do Google e uma conta de faturamento configurados, use a Vertex AI para segurança e compliance avançados.

Dependendo da opção escolhida, as próximas etapas para configurar a autenticação serão exibidas. Consulte a documentação da CLI Gemini para mais detalhes sobre essas opções.

Se você pretende usar a plataforma Vertex AI do Google Cloud, saia da CLI Gemini pressionando ctrl+c duas vezes e defina as variáveis de ambiente necessárias.

Independente do método de autenticação, geralmente é necessário definir as seguintes variáveis: GOOGLE_CLOUD_PROJECT e GOOGLE_CLOUD_LOCATION.

Para definir essas variáveis:

# Replace with your project ID and desired location (e.g., us-central1)
export GOOGLE_CLOUD_PROJECT="YOUR_PROJECT_ID"
export GOOGLE_CLOUD_LOCATION="YOUR_PROJECT_LOCATION"

Agora, faça login no Google Cloud:

gcloud auth application-default login

Depois de se autenticar com o método anterior, inicie a CLI Gemini novamente executando o comando gemini no terminal. Nas opções de autenticação, selecione Vertex AI.

Etapa 4: o teste do Spark! (Verificando sua configuração)

Este é o momento da verdade! Vamos verificar se tudo está funcionando. Execute estes comandos para garantir que todas as luzes estejam verdes.

Insira o seguinte comando:

What is my current directory?

A CLI do Gemini vai responder informando seu diretório de trabalho atual. Isso testa o modelo de linguagem principal e a integração do shell.

Testar a conexão do GCP:

list my gcs buckets

Se você tiver buckets do GCS, eles serão listados. Caso contrário, ele vai informar que não há nenhum. Isso confirma que ele está conectado corretamente ao seu projeto do GCP.

Etapa 5: mais superpoderes a ele! (Instalar extensões)

Agora vamos melhorar os recursos da CLI do Gemini instalando algumas extensões que serão úteis mais tarde no laboratório.

Cloud Run

gemini extensions install https://github.com/GoogleCloudPlatform/cloud-run-mcp

Segurança da CLI do Gemini

gemini extensions install https://github.com/gemini-cli-extensions/security

gcloud

gemini extensions install https://github.com/gemini-cli-extensions/gcloud

Cloud SQL para PostgreSQL

gemini extensions install https://github.com/gemini-cli-extensions/cloud-sql-postgresql

Se todos esses comandos funcionarem, você estará oficialmente pronto para o workshop! Seu ambiente está configurado, e você está pronto para começar a aumentar sua produtividade. Até o primeiro laboratório!

3. Principais conceitos e interação com o espaço de trabalho local

Tudo pronto para colocar as patas na massa? Agora vamos conferir as ferramentas reais no seu novo kit de ferramentas do Gemini. Penso neles como meus superpoderes para explorar e criar na nuvem. Vamos falar um pouco sobre como elas funcionam.

Recursos principais

Eu agrupo meus poderes em duas categorias: ver o que está por aí e fazer as coisas acontecerem!

Entender seu ambiente (meus superpoderes!)

Antes de começar a construir um novo ninho, você precisa verificar a árvore, certo? Essas ferramentas são para entender o cenário.

list_directory: esta é minha ferramenta básica de "farejar". É um wrapper simples em torno da listagem de diretórios padrão no nível do SO. Mas o legal é que o modelo pode analisar essa saída estruturada para tomar decisões, como escolher explorar um subdiretório chamado src.
glob: este é meu "localizador de bolotas"! Ele usa padrões glob padrão, como *, **, ? e [], que você já conhece de coisas como .gitignore. Por exemplo, você pode perguntar: "Encontre todos os arquivos *.py no diretório app" usando o padrão app/**/*.py. É uma maneira eficiente de reunir um conjunto específico de arquivos para o modelo analisar.
search_file_content: esta é minha visão de raio-x! Ele usa expressões regulares completas (regex) para as pesquisas, não apenas correspondência de strings simples. Isso é muito útil. Você pode pedir para ele encontrar padrões complexos, como "Encontre todas as rotas do Flask que usam um método POST", o que pode gerar uma regex como app\.route\(.*methods=\['POST'\].*\). Retorna o caminho do arquivo, o número da linha e a linha correspondente, fornecendo ao modelo todo o contexto necessário.
read_file: depois de encontrar um arquivo interessante, você vai querer abri-lo. O read_file é otimizado para isso. É possível ler um arquivo inteiro ou, para arquivos grandes, usar os parâmetros offset e limit para ler em partes. Isso significa que o modelo pode verificar com eficiência até mesmo arquivos de registro enormes sem atingir o tempo limite.

Da compreensão à ação (hora de criar!)

Você já explorou o terreno. Agora é hora de construir seu ninho! Com elas, você pode fazer mudanças e concluir tarefas.

**write_file**: precisa criar um arquivo do zero? write_file é uma operação atômica que grava todo o conteúdo fornecido em um caminho especificado. É perfeito para criar novos módulos ou um Dockerfile do zero com base nas necessidades do seu projeto.
**replace**: essa ferramenta é para mudanças cirúrgicas. Não é apenas uma simples ação de encontrar e substituir. Você fornece um old_string e um new_string. Para que isso funcione com segurança, o old_string precisa ser um snippet exclusivo do arquivo, geralmente com várias linhas de contexto antes e depois da parte que você está mudando. Isso garante que estamos mudando apenas a parte exact do código que você pretende.
**run_shell_command**: é o power-up máximo! Ele executa o comando especificado em um subshell bash -c <command>. O modelo retorna stdout, stderr e exit code. Isso é essencial para criar fluxos de trabalho. O modelo pode executar um terraform plan, ler a saída e, se o plano for bem-sucedido (código de saída 0), perguntar se ele deve ser aplicado.

A rede de segurança (minha promessa para você!)

Executar comandos pode ser assustador. Entendi! É por isso que a rede de segurança é tão importante. Quando o modelo gera um bloco tool_code que contém uma chamada para run_shell_command ou write_file, o cliente da CLI Gemini intercepta esse bloco. Ele mostra o comando exato ou o conteúdo completo do arquivo a ser gravado e apresenta um prompt [s/n]. Nada acontece sem sua aprovação explícita. Você está sempre no controle.

4. Como analisar um projeto

Objetivo:usar a CLI do Gemini para entender uma base de código desconhecida sem sair do terminal.

Cenário:você é um novo desenvolvedor e precisa se inteirar sobre este projeto rapidamente.

Tarefa 0: configuração: clone o projeto!

Primeiro, precisamos pegar o código. Ele está escondido em um repositório público no GitHub, em uma "árvore" chamada quickpoll. Vamos pedir para a CLI do Gemini clonar para nós. Antes disso, vamos criar um diretório de trabalho e iniciar a CLI do Gemini nele:

mkdir workdir
cd workdir
gemini

Agora, digite este comando:

clone the github repository from the URL: https://github.com/gauravkakad-google/quickpoll.git

O Gemini vai entender que "clonar" significa usar o comando git clone. Isso vai gerar uma chamada de ferramenta run_shell_command com algo como git clone https://github.com/gauravkakad-google/quickpoll.git. Depois que você aprovar, o repositório será baixado.

Agora, vamos sair da CLI do Gemini pressionando ctrl+c duas vezes, navegar até o repositório de amostra e iniciar a CLI do Gemini novamente:

cd quickpoll
gemini

Ótimo! Agora que estamos na árvore de projetos, podemos começar a explorar.

Tarefa 1: listar todos os arquivos do projeto

Agora que estamos dentro, vamos mapear toda a floresta. Queremos ver todos os arquivos. Pergunte ao Gemini:

List all the files in the project.

O Gemini provavelmente vai usar a ferramenta glob com o padrão **/*. Isso lista recursivamente todos os arquivos, oferecendo um manifesto completo da base de código. É um ótimo primeiro passo para entender a estrutura do projeto.

Tarefa 2: encontrar todos os arquivos que importam "google.cloud.sql.connector"

Ok, estou curioso. Onde esse projeto se comunica com o Google Cloud Storage? Vamos fazer um trabalho de detetive. Pergunte:

Find all files that import the 'google.cloud.sql.connector' library.

Usando o poder do search_file_content, o Gemini vai encontrar os arquivos exatos que contêm essa instrução de importação. Isso restringe imediatamente o foco às partes do código que processam a interação com o Cloud SQL. Neste projeto, ele deve encontrar backend/main.py.

Tarefa 3: mostre o conteúdo do Dockerfile principal

Vejo um Dockerfile! Esse é o blueprint do nosso contêiner. Vamos dar uma olhada. Basta perguntar:

Show me the contents of the main Dockerfile.

O Gemini vai usar read_file para mostrar o Dockerfile. Você pode analisar a imagem de base (FROM), as dependências que estão sendo instaladas (RUN pip install...) e o comando final (CMD). Isso informa sobre o ambiente de execução do aplicativo.

Tarefa 4: qual é a finalidade do arquivo `main.py`?

Agora vamos analisar o coração do código. Vamos pedir ajuda ao Gemini. Diga:

What's the purpose of the `main.py` file?

É aí que a CLI do Gemini se destaca. Primeiro, ele vai chamar read_file em backend/main.py. Em seguida, o modelo de linguagem multimodal vai analisar o código Python. Ele vai identificar que é um aplicativo FastAPI que fornece uma API REST para um aplicativo de pesquisa. Em seguida, vamos explicar os endpoints da API e a funcionalidade deles. Isso poupa o tempo de ter que ler e decifrar tudo sozinho. Você também pode fazer perguntas complementares para explicar algumas dessas funcionalidades em detalhes. Muito legal, não é? Faça um teste!

5. Do local para o ao vivo! Implantação com o Cloud Run e o Cloud SQL

Muito bem, aventureiro da nuvem, você já explorou o território. Agora é hora de construir sua própria casa na árvore na nuvem. Vamos pegar nosso aplicativo de enquete rápida e transformá-lo em um app da Web real e ativo que qualquer pessoa pode acessar.

Objetivo: implantar o aplicativo quickpoll no Cloud Run com um back-end do Cloud SQL para PostgreSQL.

Tarefa 1: um ramo resistente para nossos dados (configuração do Cloud SQL)

Todo bom aplicativo precisa de um lugar para armazenar suas preciosas bolotas... Quero dizer, dados! Vamos usar o Cloud SQL para PostgreSQL. É como um jardim mágico e autônomo para nosso banco de dados, assim podemos nos concentrar nas coisas divertidas.

Vamos pedir para a CLI do Gemini plantar a semente do nosso banco de dados.

Please create a new Cloud SQL for PostgreSQL instance for me in project <myproject>. Call it quickpoll-db and put it in us-central1. Lets use the Development preset for now, and make the root password a-very-secure-password!.

A CLI Gemini, usando a extensão do Cloud SQL, vai começar a trabalhar. Ela vai mostrar a chamada de função create_instance. Aprove!

Depois que a instância for criada, você vai receber uma saída semelhante a esta:

Você pode criar um arquivo .env com a variável de ambiente acima e usar a origem dele antes de reiniciar a CLI do Gemini para que ela tenha acesso a essas variáveis.

Enquanto a instância cresce, vamos preparar o solo. Precisamos de um banco de dados e um usuário para nosso app.

In the quickpoll-db instance, create a new database named quickpolldb.

A CLI do Gemini vai usar a ferramenta create_database na extensão do Cloud SQL para PostgreSQL para criar o banco de dados.

Agora vamos adicionar um usuário para cuidar dele:

In the quickpoll-db instance, create a built in user named quickpoll-user with the password another-secure-password!.

Desta vez, a CLI Gemini vai usar a ferramenta create_user.

Tarefa 2: o caminho secreto (conexão do back-end)

Nosso back-end precisa saber o caminho secreto para o novo banco de dados. Vamos dar uma olhada em backend/main.py para ver como ele funciona.

show me how would the backend/main.py connect to the database

Aha! Viu? Ele usa o conector Python do Cloud SQL e procura variáveis de ambiente como CLOUD_SQL_POSTGRES_INSTANCE, CLOUD_SQL_POSTGRES_USER, CLOUD_SQL_POSTGRES_PASSWORD e CLOUD_SQL_POSTGRES_DATABASE. Precisamos fornecer esses dados ao nosso serviço do Cloud Run.

Primeiro, precisamos da CLOUD_SQL_POSTGRES_INSTANCE. É como um aperto de mão secreto.

What are the details for the Cloud SQL instance quickpoll-db in us-central1?

Vários detalhes vão aparecer. Procure o nome da conexão e copie esse valor. Ele vai ficar parecido com your-project-id:us-central1:quickpoll-db.

Antes de implantar o aplicativo no Cloud Run, vamos instanciar o banco de dados com as tabelas necessárias. Como criamos um banco de dados e um usuário separados, vamos sair da CLI do Gemini e atualizar o .env que criamos antes com os novos valores:

export CLOUD_SQL_POSTGRES_USER=quickpoll-user
export CLOUD_SQL_POSTGRES_PASSWORD=password-you-provided
export CLOUD_SQL_POSTGRES_DATABASE=quickpolldb

Agora reinicie a CLI do Gemini e insira o seguinte:

execute backend/database.sql file on quickpolldb database as quickpolluser in quickpoll-db instance

Ele descobriu automaticamente que a ferramenta execute_sql não permite executar vários comandos SQL em uma única chamada. Então, ele executou cada comando SQL separadamente.

Tarefa 3: backend, decole! (Como implantar no Cloud Run)

É hora de o back-end sair do ninho! Vamos pedir ao Gemini para implantar a pasta de back-end no Cloud Run e dar a ela o caminho secreto para o banco de dados.

Deploy the backend folder to a new Cloud Run service called quickpoll-be in us-central1. Here are the secrets (environment variables):
CLOUD_SQL_POSTGRES_INSTANCE=your-project-id:us-central1:quickpoll-db
CLOUD_SQL_POSTGRES_USER=quickpoll-user
CLOUD_SQL_POSTGRES_PASSWORD=password-you-provided
CLOUD_SQL_POSTGRES_DATABASE=quickpolldb

O Gemini vai empacotar seu código, criar uma imagem de contêiner e implantá-la no Cloud Run. Depois de alguns minutos, você vai receber um URL para seu novo serviço de back-end. Mantenha esse URL à mão.

Tarefa 4: os toques finais (configuração e implantação do front-end)

Nosso front-end é como o rosto amigável do aplicativo. Ele precisa saber onde encontrar o back-end. Vamos dizer para onde ir.

Deploy the frontend folder to a new Cloud Run service called quickpoll-fe in us-central1. Here are the secrets (environment variables):
BACKEND_URL=backend-url

Tarefa 5: a grande revelação!

Isso é tudo. A hora da verdade! Pegue o URL do serviço quickpoll-fe e abra-o no navegador da Web.

O aplicativo QuickPoll vai aparecer, pronto para ser usado. Crie uma enquete, vote e veja os resultados atualizados em tempo real.

Você conseguiu! Você pegou um projeto da sua máquina local e o colocou em prática no Google Cloud. E você fez tudo isso no conforto do seu terminal com seu fiel companheiro, a CLI do Gemini.

Isso sim é produtividade!

6. Para desenvolvedores: como acelerar o ciclo de vida de desenvolvimento

Desenvolvedores, agora a diversão começa de verdade! Já conhecemos um projeto, mas agora é hora de criar. Vou mostrar como o Gemini pode ser seu parceiro de programação definitivo, ajudando você a transformar uma ideia simples em código pronto para produção mais rápido do que um esquilo encontra uma noz!

Da ideia ao código

Pense no ciclo de desenvolvimento típico. Não é só escrever código, certo? É scaffolding, adição de tratamento de erros, refatoração e gravação de testes. O Gemini pode ajudar com tudo isso!

Texto padrão e tarefas repetitivas: chega de copiar e colar!

Ok, você tem a funcionalidade básica do aplicativo. Agora você precisa adicionar geração de registros e processar possíveis erros, certo? Geralmente, são muitos blocos try...except repetitivos. Não mais! Vamos começar pedindo à CLI do Gemini para analisar o código e sugerir recomendações de práticas recomendadas para registro de erros e tratamento de exceções:

What are the best practices for error handling and logging that should also be included in this application?

A CLI do Gemini vai analisar o arquivo atual e fornecer algumas recomendações de práticas recomendadas. É como um assistente especializado que economiza seu tempo de pesquisa.

Agora, peça para ele implementar essas recomendações para você:

please go ahead and implement these in the existing app

A saída real pode ser diferente no seu caso, mas, no final, você vai ver os detalhes das mudanças feitas. Por exemplo, na captura de tela abaixo, é possível ver que ele adicionou structlog para produzir registros formatados em JSON, implementou o tratamento centralizado de exceções e melhorou a maneira como as respostas de solicitação são registradas. Pense em tudo que você acabou de economizar de digitação!

Refatoração: seu revisor de código pessoal

Todos queremos escrever um código limpo e eficiente. Mas, às vezes, estamos com pressa. O Gemini pode ser seu revisor de código pessoal. Você pode perguntar coisas como:

please perform a comprehensive code review for best practices and security

O Gemini entende as práticas recomendadas específicas de cada idioma. A saída real no seu caso pode ser diferente das capturas de tela acima, mas, se você ler a saída, vai perceber o nível de detalhes que a CLI do Gemini usou para analisar o código. Ele ajuda você a aprender e melhorar seu código ao mesmo tempo.

Geração de teste: a melhor parte!

Este é meu truque favorito! Todos sabemos que devemos escrever testes, mas isso pode ser tedioso, especialmente quando você precisa simular coisas. Vamos dar uma olhada. Basta perguntar:

Add a test suite to this application

O Gemini vai analisar sua função, identificar as entradas e saídas e descobrir quais são as dependências dela. Em seguida, ele vai gerar um arquivo test_main.py completo com vários casos de teste, incluindo um "caminho feliz" e talvez uma condição de erro. Isso aumenta muito a produtividade.

Execute os testes! (Um desafio para você)

Agora é que as coisas ficam realmente interessantes! Vou deixar essa parte como um desafio para você explorar de forma independente. Peça à CLI do Gemini para executar os casos de teste gerados. Depois, é só relaxar e observar a mágica acontecer!

7. Além do localhost: integração com o GitHub

Fizemos um trabalho incrível na nossa máquina local, nosso próprio cantinho da floresta. Mas o verdadeiro poder da nuvem é a colaboração e a conexão. É hora de decolar e descobrir como o Gemini pode interagir com o mundo, começando pela maior árvore da floresta de desenvolvedores: o GitHub.

Conceito: seu assistente integrado de DevOps

Até agora, usamos o Gemini como um parceiro de programação local. Agora, vamos fazer upgrade para um Assistente de DevOps integrado completo. Tudo isso graças à integração do Protocolo de Contexto de Modelo (MCP). É um nome sofisticado, mas significa apenas que o Gemini pode conversar com segurança com outros serviços em seu nome. O primeiro que vamos dominar é o GitHub.

Pense nisso. Com que frequência você precisa sair do terminal para verificar uma solicitação de envio, criar um problema ou navegar em um repositório no GitHub? Isso é mais troca de contexto! Com o conjunto de ferramentas github, você pode fazer tudo isso aqui mesmo. Ele transforma o Gemini em uma interface nativa para o GitHub.

A documentação oficial do servidor MCP do GitHub oferece muitas orientações sobre as ferramentas expostas e as opções de configuração. Você pode escolher entre a operação local ou remota, já que a CLI do Gemini é totalmente compatível com os dois servidores MCP remotos.

Este tutorial vai orientar você na configuração da opção de servidor MCP remoto para o GitHub. Primeiro, você vai precisar de um token de acesso pessoal (PAT) do GitHub.

Depois de ter o PAT, é hora de adicionar o objeto do servidor MCP ao arquivo settings.json. Minhas configurações completas em settings.json são mostradas abaixo, mas você pode simplesmente garantir que seu objeto mcpServers corresponda ao que você vê aqui:

{
  "security": {
    "auth": {
      "selectedType": "vertex-ai"
    }
  },
 "mcpServers": {
    "github": {
      "httpUrl": "https://api.githubcopilot.com/mcp/",
      "headers": {
        "Authorization": "GITHUB_PAT"
      },
      "timeout": 5000
    }
  }
}

Depois de atualizar o settings.json com a configuração do servidor MCP do GitHub, reinicie a CLI do Gemini ou execute o comando /mcp refresh. A captura de tela abaixo mostra o servidor MCP do GitHub agora preparado no meu sistema, exibindo a variedade de ferramentas poderosas que a CLI do Gemini pode usar com o protocolo de contexto de modelo.

Demonstração dos principais comandos

O Gemini vem com um novo conjunto de superpoderes especificamente para o GitHub. Confira alguns dos meus favoritos:

github.list_repositories: quer ver todos os repositórios da sua organização sem abrir um navegador? Esta é sua ferramenta! Basta perguntar: "Liste todos os repositórios na minha organização".
github.create_issue: encontrou um bug? Não mude de janela para criar um problema. Basta dizer ao Gemini: "Crie um problema no repositório sample-flask-app com o título "Corrigir o bug de login" com esta descrição..." e pronto, o problema será criado.
github.get_pull_request: precisa verificar uma RP? Você pode perguntar: "Mostre os detalhes da solicitação de pull número 42 no repositório sample-flask-app". O Gemini vai buscar o título, a descrição, o status e quem são os revisores.
github.get_file_contents: este é muito legal. É possível ler um arquivo de um repositório remoto sem precisar cloná-lo primeiro. É ótimo para verificar rapidamente um arquivo de configuração ou o README de um projeto que você não tem localmente.

8. Exploração do GitHub

Vamos parar de falar e voar! Vamos usar nossos novos poderes do GitHub para explorar uma organização e um projeto, tudo no conforto do nosso terminal.

Objetivo: usar o Gemini para explorar e entender um projeto hospedado no GitHub.

Cenário: você precisa conhecer um projeto no GitHub em que nunca trabalhou.

Tarefa 1: listar repositórios em uma organização

Primeiro, vamos conferir todos os projetos em uma organização do GitHub. Neste laboratório, você pode usar seu próprio nome de usuário do GitHub ou uma organização a que pertence. Vamos pedir ao Gemini para listar.

List the repositories in the `[your-org-or-username]` GitHub organization.

Substitua [your-org-or-username] pelas suas informações reais. O Gemini vai usar a ferramenta github.list_repositories e mostrar uma lista de todos os projetos. Incrível!

Tarefa 2: encontrar um repositório específico

Ok, você vai ver uma lista de repositórios. Agora, assim como um desenvolvedor de verdade, você precisa analisar essa lista e encontrar o projeto em que tem interesse. Para nosso laboratório, vamos fingir que estamos procurando o repositório quickpoll que clonamos antes. Você não precisa de um comando para esta parte. Basta ler a saída da última etapa e encontrar o repositório.

Tarefa 3: listar solicitações de envio abertas

Agora que identificamos o repositório de destino, vamos ver o que está acontecendo com ele. Há solicitações de envio abertas? Vamos perguntar:

List the open pull requests for the `quickpoll` repository in the `[your-org-or-username]` organization.

O Gemini vai usar a ferramenta github.list_pull_requests, filtrando o estado open. Em seguida, ele vai listar todos os PRs abertos, mostrando o número, o título e quem criou. Essa é uma visão instantânea do desenvolvimento ativo do projeto. Você pode testar isso com um repositório em que está contribuindo ativamente e verificar os resultados.

Tarefa 4: investigar uma solicitação de envio

Digamos que haja uma RP interessante nessa lista. Queremos saber mais sobre isso! Queremos ver a descrição e quais arquivos foram alterados. Escolha um número de PR na lista. Se não houver nenhum, pule esta etapa.

Show me the details and files changed in PR number 1 in the `quickpoll` repo.

Esse é um ótimo exemplo de tarefa de várias etapas para o Gemini. Primeiro, ele provavelmente usará github.get_pull_request para buscar os principais detalhes: título, corpo, autor etc. Depois, para receber as mudanças no arquivo, ele usará uma segunda ferramenta, github.get_pull_request_files. Em seguida, ele combina todas essas informações em um resumo claro e conciso para você. Você acabou de analisar uma solicitação de pull sem sair do terminal! Não é incrível?

9. Do PRD ao commit inicial

Você aprendeu a explorar, criar e testar. Agora vamos juntar tudo isso em um cenário real. É o momento em que transformamos um plano em um produto. Vamos do documento de requisitos do produto (PRD) até nosso primeiro commit. Vamos construir algo incrível!

Objetivo: simular uma tarefa de desenvolvimento do mundo real do início ao fim, combinando contexto local e remoto.

Cenário: você recebeu um novo recurso! Os requisitos estão em um arquivo PRD no repositório do GitHub do projeto.

Tarefa 1: entender – leia o PRD

Esta é a etapa mais importante. Antes de pensar em escrever uma única linha de código, você precisa entender o plano. Os requisitos do nosso novo recurso estão no arquivo prd/NEW_FEATURE.md. Vamos abrir e ver o que tem dentro.

explain the requirements mentioned in prd/NEW_FEATURE.md

A CLI Gemini vai usar read_file para mostrar o conteúdo do PRD. Mergulhe fundo! Ele vai descrever o novo recurso: um botão "Atualizar" para que os usuários atualizem manualmente a lista de enquetes ativas. Sempre consulte o projeto primeiro.

Tarefa 2: codificar: traduzir requisitos em realidade

Este é o momento mágico! Vamos pegar os requisitos do PRD e pedir para o Gemini escrever o código. Vamos ser específicos e dizer exatamente o que queremos.

Implement the changes as per the PRD

A CLI do Gemini vai entrar em ação e, depois de um momento, você vai ver uma saída parecida com esta. Nosso novo código brilhante agora tem um lar aconchegante!

Tarefa 3: verificar as mudanças

Criamos um novo arquivo com um novo código. A última etapa deste laboratório é implantar a mudança no Cloud Run e verificar.

let's deploy the changes made to frontend to Cloud Run. The existing service on Cloud Run is quickpoll-fe in us-central1.

Observe como essa solicitação forneceu mais detalhes, como o nome do serviço do Cloud Run e a região de implantação. Ser específico ajuda a economizar tempo, mas a CLI do Gemini sempre vai pedir os detalhes que faltam se você não os incluir.

Se o serviço atualizado do Cloud Run encontrar um erro, basta pedir à CLI do Gemini para depurar e corrigir o código. Lembre-se de que ele é seu companheiro superpoderoso!

10. Parabéns

E isso é tudo! Você acabou de concluir um ciclo de desenvolvimento completo. Você passou de um documento de requisitos para um novo recurso, pronto para ser confirmado e enviado. Você combinou contexto local, contexto remoto, operações do sistema de arquivos e geração de código. Você não é apenas um desenvolvedor, mas um arquiteto de nuvem superprodutivo. Parabéns!