Laravel em qualquer máquina de desenvolvedor com Gitpod

Se você já é desenvolvedor há tempo suficiente, já se deparou com a emoção de clonar um novo repositório e ficou rapidamente gorado por não conseguir compilar ou executar o código em sua máquina. Há muito tempo que resolvi esse repto usando o Docker e, mais especificamente, o Docker Compose para fornecer uma maneira consistente de erigir e testar código localmente. Embora não seja perfeito, é uma melhoria, mas ainda falta em muitos aspectos. Mas e se houvesse uma maneira de ter um envolvente de desenvolvimento consistente que também permitisse padronização e automação? Digitar Gitpodum envolvente de desenvolvimento em nuvem criado para resolver exatamente esses problemas.

Porquê desenvolvedor de PHP e Laravel, muitas vezes tenho dificuldades com versões de servidor, empacotamento consistente de arquivos, migrações de banco de dados e realização de recursos localmente para poder codificar e testar minhas alterações com precisão. Neste cláusula, vou percorrer uma forma básica de uma vez que transformar um repositório Laravel em um Projeto Gitpod. A partir desse projeto, destacarei alguns recursos do uso do Flex do Gitpod para percorrer as alterações no código sítio e uma vez que qualquer novo desenvolvedor pode clonar meu repositório e ter um envolvente sítio totalmente funcional através do poder da plataforma Gitpod.

#Divulgação

Mas antes de começarmos e para divulgação, Gitpod me patrocinou para testar seu resultado e relatar minhas descobertas. Eles alugaram minha atenção, mas não minha opinião. Cá está minha visão justo da minha experiência uma vez que desenvolvedor ao configurar um espaço de trabalho Gitpod para codificação em um aplicativo PHP e Laravel

#O problema do Gitpod

Sou desenvolvedor desde meados da dezena de 1990 e experimentei todos os problemas que o Gitpod está resolvendo. Problemas uma vez que configurar um desenvolvimento sítio, obter uma compilação e enviá-la para um servidor (ou nuvem). Estes parecem essenciais, mas existem outros desafios além da experiência de um único desenvolvedor. A imagem aquém é um visual fantástico para o espaço em que a utensílio está operando.

Com as ferramentas e os problemas estabelecidos, vamos passar para o código e ver uma vez que o Gitpod e o Laravel funcionam juntos com uma forma sítio.

#Emprego Laravel

Para lastrar o cláusula, trabalharei com um aplicativo Laravel capital que usa um banco de dados SQLite uma vez que única obediência externa. O código nascente completo pode ser encontrado em levante repositório Github

#Começando

Normalmente, quando inicio um projeto Laravel, início com:

laravel new example-app

No entanto, para aproveitar as vantagens do Gitpod, preciso erigir em um envolvente em contêiner. Para resolver isso, estou me inclinando para Velejar. Sail me dá uma maneira de erigir meu aplicativo PHP para um envolvente Docker e fornece um gerado docker-compose.yml que posso personalizar de concórdia com minhas necessidades.

Tudo isso apoia a construção e interação com meu envolvente de desenvolvimento em um DevContainer. DevContainers podem ser descritos assim:

Um contêiner de desenvolvimento (ou contêiner dev, abreviadamente) permite que você use um contêiner uma vez que um envolvente de desenvolvimento completo. Ele pode ser usado para executar um aplicativo, para separar ferramentas, bibliotecas ou tempos de realização necessários para trabalhar com uma base de código e para facilitar na integração e testes contínuos. Os contêineres de desenvolvimento podem ser executados sítio ou remotamente, em uma nuvem privada ou pública, em uma variedade de ferramentas e editores de suporte – Site DevContainers

Se você não está familiarizado com DevContainers, cá está o site isso pode ajudá-lo a saber por que você deve prestar atenção e aproveitá-los.

No contexto do Gipod, a especificação DevContainer é integrada nativamente e é secção integrante da experiência do desenvolvedor. Para o meu exemplo, cá está o .devcontainers/devcontainer.json no meu projeto.

{
    "name": "Existing Docker Compose (Extend)",
    "dockerComposeFile": [
        "../docker-compose.yml"
    ],
    "service": "laravel.test",
    "workspaceFolder": "/var/www/html",
    "customizations": {
        "vscode": {
            "extensions": [
            ],
            "settings": {}
        }
    },
    "remoteUser": "sail",
    "postCreateCommand": "chown -R 1000:1000 /var/www/html 2>/dev/null || true"
}

Com a forma do projeto e as seguintes personalizações Sua visita nos ajuda a continuar oferecendo o melhor para você! meu aplicativo simples se parece com a imagem aquém dos marcadores.

• Adicionado um padrão Todo
• Adicionada uma transmigração de tarefas
• Adicionado um Todo Seeder
• Personalização do CSS e UI do TodoView
• Modificou as rotas para indicar / no meu TodoController que produz uma lista Sua visita nos ajuda a continuar oferecendo o melhor para você! Todos

#Mergulhando no Gitpod

Se você falar com um desenvolvedor que trabalha em qualquer aplicativo com mais de duas dependências, ele terá os mesmos problemas comuns que lhe contará. O gerenciamento de dependências no nível do sistema operacional e da livraria pode ser complicado. Manter um banco de dados atualizado com o qual o aplicativo é congruente dá trabalho. E muitas vezes esquecem de realizar migrações e perdem horas de suas vidas percebendo que precisavam realizar uma transmigração. Ou pior ainda, eles se juntaram a uma novidade equipe e perderam muitos dias unicamente configurando o projeto.

Agora pegue tudo isso e o trabalho necessário para fazer as coisas localmente e tente levar esse esforço para a equipe de DevOps e plataforma. É quase uma vez que reiniciar e pode ser uma dança frágil de tradução entre o sítio e a nuvem. Imagine poder satisfazer tanto a equipe de desenvolvimento quanto a equipe da plataforma. Nascente é o problema e o espaço em que o Gitpod vive.

Meu exemplo aquém vai unicamente escoriar a superfície. Ele fará uso de PHP, Laravel, DevContainers, Flex do Gitpod, um Gitpod Runner sítio e algumas automações básicas do Gitpod. A partir daí, deixarei alguns próximos passos que você pode seguir para estugar seu tirocínio.

#Projetos e ambientes Gitpod

Gitpod opera em torno de projetos e ambientes. Meu projeto está conectado diretamente ao meu repositório Github que compartilhei supra. Na UI, isso é representado em uma visualização Projetos.

Depois de estabelecer um projeto, posso gerar um envolvente. Os ambientes podem ter Runners onde seu contêiner está hospedado. Para mim, estou executando em um Sítio Runner, mas esta poderia facilmente ser uma região na AWS onde eu teria um servidor EC2 rodando em uma VPC e sub-rede de minha escolha.

#Galeria Sítio

Depois de estabelecer essas duas construções básicas no Gitpod, estou pronto para lançar meu envolvente sítio. É cá que entra o DevContainer. O Gitpod lerá aquela especificação que aponta para um registro Docker Compose que iniciará o contêiner no qual posso codificar.

services:
    laravel.test:
        build:
            context: './.devcontainer'
            dockerfile: Dockerfile
            args:
                WWWGROUP: '1000'
        image: 'sail-8.3/app'
        extra_hosts:
            - 'host.docker.internal:host-gateway'
        ports:
            - '${APP_PORT:-80}:80'
            - '${VITE_PORT:-5173}:${VITE_PORT:-5173}'
        environment:
            WWWUSER: '1000'
            LARAVEL_SAIL: 1
            XDEBUG_MODE: '${SAIL_XDEBUG_MODE:-off}'
            XDEBUG_CONFIG: '${SAIL_XDEBUG_CONFIG:-client_host=host.docker.internal}'
            IGNITION_LOCAL_SITES_PATH: '${PWD}'
        volumes:
            - '.:/var/www/html'
        networks:
            - sail
        depends_on: {  }
networks:
    sail:
        driver: bridge

Quando clico em iniciar e as coisas acontecem do meu jeito, recebo a seguinte imagem com todos esses círculos verdes. Os círculos vermelhos seriam ruins e eu teria registros e informações sobre o que poderia ter oferecido incorrecto.

#Automações

Neste ponto, você deve estar se perguntando quais são esses serviços e tarefas na secção intermediária e subalterno da imagem. O Gitpod vai além do DevContainers e oferece a capacidade de personalizar a forma uma vez que as coisas são iniciadas. As automações são poderosas e muito mais pode ser leia cá.

Essencialmente, pense neles assim. Recebo pontos na inicialização onde posso executar comandos em meu contêiner. Por exemplo, talvez eu queira executar uma transmigração de banco de dados. Ou talvez eu queira compose algumas dependências para minha emprego Laravel? Elas seriam chamadas de Tarefas.

Mas e quanto a coisas de longa duração, uma vez que o próprio aplicativo PHP? Isso seria feito por meio de Serviços. E toda essa automação acontece incluindo um .gitpod/automations.yaml registro no meu projeto. No meu caso, é parecido com o aquém. Optei pela granularidade em vez de fazer tudo em uma tarefa unicamente para visualizar melhor as coisas.

services:
  php:
    name: Run PHP Serve
    triggeredBy: ["postDevcontainerStart"]
    commands:
      start: php artisan serve
 
tasks:
  copyEnv:
    name: Copy Environment
    description: Creates the .env file
    triggeredBy:
      - postEnvironmentStart
    command: cp .env.example .env
  appUrl:
    name: Mod App URL
    dependsOn: ["copyEnv"]
    triggeredBy:
      - postEnvironmentStart
    command: sed -i "s#APP_URL=http://localhost#APP_URL=$(gp url 8000)#g" .env
  viteUrl:
    name: Mod Vite URL
    dependsOn: ["copyEnv"]
    triggeredBy:
      - postEnvironmentStart
    command: sed -i "s#GITPOD_VITE_URL=#GITPOD_VITE_URL=$(gp url 5173)#g" .env
  composer:
    name: Install Dependencies
    dependsOn: ["copyEnv"]
    triggeredBy:
      - postEnvironmentStart
    description: Installs deps via composer
    command: composer install --ignore-platform-reqs
  createDatabase:
    name: Create Database
    triggeredBy:
      - postEnvironmentStart
    dependsOn: ["copyEnv"]
    command: touch database/database.sqlite
  phpOperations:
    name: Setup PHP and Run
    triggeredBy:
      - postEnvironmentStart
    dependsOn: ["copyEnv"]
    command: |
      php artisan key:generate
      php artisan storage:link
      php artisan migrate --seed
      php artisan db:seed --class=TodoSeeder

Incrível né?!? Posso executar essas etapas ao iniciar meu envolvente de desenvolvimento. E qualquer desenvolvedor que tenha aproximação a levante projeto recebe o mesmo. E digamos que eu precise modificar as etapas ou o fluxo de trabalho na próxima vez que iniciar. Esses simplesmente são executados. Muito melhor do que um registro README.md que poder estar desatualizado.

#Conectando-se ao Meu Editor

Ao usar o cliente Gitpod, posso conectar meu editor ou terminal ao meu contêiner. Para isso optei pelo VSCode devido à sua popularidade. No entanto, há uma integração para IDEs Jetbrains e também posso conectar meu editor predilecto no Neovim por meio de Dotfiles personalizados. O desenvolvedor de terminal que existe em mim é encorajado por esse suporte e pretendo me aprofundar nessa espaço conforme tiver tempo.

VSCode tem duas extensões interessantes para trabalhar com Gitpod e DevContainers. Descobri que depois de lançar meu envolvente Gitpod no VSCode, era uma vez que trabalhar com desenvolvimento sítio normal. As alterações estão disponíveis imediatamente e todas as operações normais do Git funcionam exatamente uma vez que eu esperava. E, novamente, tudo isso está acontecendo em um Container, logo não se preocupe com dependências locais ou “funciona na minha máquina”.

A última peça do quebra-cabeça é ter certeza de que tenho portas expostas ao meu contêiner para que eu possa servir o tráfico do serviço Gitpod em realização, que é unicamente php artisan serve. Depois que tudo estiver pronto, posso servir o tráfico em meu navegador que mostra um aplicativo PHP Laravel, bem por SQLite que foi migrado e propagado conforme minhas automações de tarefas especificadas.

E o melhor é que posso compartilhar isso com qualquer colega de equipe e, no tempo que leva para extrair os recursos do Gitpod e do DevContainer, inicializar e lançar, eles terão a mesma experiência. Existem tantos problemas resolvidos.

#Impressões e pensamentos

Eu não tinha pretérito muito tempo com CDEs no pretérito, mas estou muito impressionado com o que o Gitpod está montando. Acho que o poder está na sua repetibilidade e na capacidade de automatizar tantas tarefas rotineiras de uma forma consistente que não é específica do tempo de realização é simplesmente mágica.

Não tive a chance neste cláusula de explorar a realização de um projeto na nuvem, mas a partir da minha exploração da documentação, posso conectar esse mesmo projeto à AWS por meio de um padrão CloudFormation gerado. E uma vez que o Gitpod vem com uma CLI, o mesmo trabalho que faço localmente pode ser conectado a um pipeline automatizado uma vez que secção de um processo de CI/CD que pode estugar o envio de valor aos clientes.

Eu tive alguns solavancos ao longo do caminho. O Gitpod lançou recentemente seu resultado Flex, no qual levante cláusula se baseia.

Primeiro, a documentação é boa, mas os tutoriais deixaram um pouco a desejar, logo tive que deslindar alguns padrões específicos e uma vez que a UI do cliente funcionava. Esperamos que levante cláusula e o código que o acompanha evitem alguns deles.

Em segundo lugar, a UI é muito boa para um lançamento antecipado, mas ainda faltam algumas opções, uma vez que atualizar meu repositório Git se eu mudar um tanto fundamental. E descobri que, ao mudar para a novidade CLI, não consegui realizar as coisas que pensei que poderia na documentação.

Os problemas, entretanto, são totalmente compensados ​​pelo vestuário de o software funcionar de maneira incrível. E combine isso com um ciclo de desenvolvimento ativo dos repositórios Github do Gitpod e as coisas só vão melhorar à medida que o Flex continua a decolar. Estou seriamente impressionado com o fluxo de trabalho e a economia de tempo que isso poderia proporcionar a uma equipe maior de desenvolvimento de software.

#Concluindo

Meu objetivo com levante cláusula foi fornecer uma introdução básica à realização de um aplicativo Laravel desenvolvido em Gitpod com DevContainers e Flex UI Client. Há muito mais no ecossistema que vale a pena explorar. Você poderia reprofundar mais no Gitpod, na especificação DevContainers, ou melhorar os Dockerfiles básicos com os quais estou trabalhando neste projeto.

O que acredito ser poderoso na abordagem CDE é que, uma vez que desenvolvedor, você poderia fazer parcerias melhores com suas equipes de plataforma para compartilhar secção da trouxa de implantação e provisionamento usando as abstrações que Sua visita nos ajuda a continuar oferecendo o melhor para você! fornece. Você também obtém um cimalha nível de isolamento e segurança ao adotar essa abordagem. Os ambientes podem ser isolados em estações de trabalho ou servidores. Você também pode usar configurações em nível de locatário. E, por último, cada operação executada é verificada por credenciais e autorizações na API Gitpod.

O desenvolvimento está avançando rapidamente. Essa abordagem oferece o controle e o conforto de que as bases do seu dia a dia sejam controladas, gerenciadas e protegidas.

Obrigado pela leitura e boa construção!