Uma introdução ao DevKinsta

TL;DR: Por quanto este post pode soar como uma revisão paga ou promovida, não é. O resumo é que eu tenho hospedado este site na Kinsta há alguns anos e estou feliz e continuamente impressionado com a oferta deles, então quando eles anunciaram seu aplicativo DevKinsta, eu estava tão interessado em experimentá-lo como estive com Local, Valet, MAMP e outros.

Resumindo, o DevKinsta se apresenta como uma forma de :

Projete, desenvolva e implante sites WordPress no conforto de sua máquina local. O DevKinsta é gratuito para sempre e está disponível para macOS e Windows.

Kinsta

Mas em vez de percorrer os vídeos e outros materiais que o site tem a oferecer, pensei em passar pelo processo de configuração do download à configuração do site, da criação de um site ao carregamento em um navegador e veja como tudo está configurado dentro da estrutura do arquivo.

DevKinsta: Do download à configuração do site

Para quem está curioso, estou instalando o DevKinsta no Mac Mini 2018 (então, sim, é baseado em Intel).

Instalação e lançamento

Depois de seguir as etapas típicas para baixar e instalar um aplicativo para Mac:

Em seguida, iniciei [usando o holofote] e fui recebido com a seguinte imagem:

A primeira coisa que me chamou a atenção foi que estava instalando imagens do Docker . Eu usei o Docker em várias encarnações há anos. Recebo todas as vantagens – ou seja, não preciso ser convencido de seus benefícios – mas geralmente não sou fã dele. Tem seus defeitos, mas esse não é o post para isso.

De qualquer forma, quando vejo isso durante a instalação, me dá uma pausa, especialmente porque software como Local Lightning – que claramente será uma competição natural para isso – está usando hardware nativo.

O painel principal

Dito isso, o painel principal fica assim:

Eu gosto que ele oferece a capacidade de configurar um novo site, importar um site que você já tem rodando no Kinsta (o que é algo que eu ficaria surpreso em não ver, na verdade), ou configurar um site com configuração personalizada.

Uma configuração de site personalizada

Por causa deste artigo, vou configurar um site personalizado para dar uma olhada na aparência das opções.

Na tela acima, adicionei o seguinte:

• Nome do Site: Playground
• Domínio :playground.local
• Localização do site: /Users/tommcfarlin/DevKinsta/public/playground
• Tipo de servidor Web: Nginx (embora esta seja a única opção)
• Versão do PHP: 7.4 (embora 7.2, 7.3 e 8.0 estejam disponíveis)
• Nome do banco de dados: playground
• Ativar HTTPS: Sim
• Título do site WordPress: WordPress Playground
• E- mail do administrador do WordPress :info@playground.local

Eu então forneci um nome de usuário e fui com a senha que foi gerada para mim. Neste ponto durante a configuração, não sei se as credenciais para login serão armazenadas em algum lugar, então copiei o login e a senha para o meu gerenciador de senhas por precaução.

Depois disso, fui solicitado a inserir minhas credenciais de administração do sistema para atualizar os arquivos de hosts e para adicionar um certificado SSL (ambas ações que eu esperava ver) enquanto o DevKinsta configurava o software.

Em seguida, foi-me dada a tela inicial do projeto que se parece com o seguinte:

Isso não é diferente de outras ferramentas semelhantes. Eu gosto da capacidade de alternar WP_DEBUGfacilmente a partir do painel. Em ambientes de desenvolvimento, acho que é uma boa ideia tê-lo sempre, mas dependendo de quais são suas necessidades ou no que você está trabalhando, talvez não seja necessariamente algo que você precise.

Gosto que todas as informações estejam disponíveis em uma única tela, especialmente as informações do banco de dados, para que eu possa usar minha ferramenta preferida para acessar o banco de dados. O aplicativo integrado é uma versão personalizada do Adminer.

Antes de carregar o site e ver como fica a área de administração, também estou curioso para ver como é a estrutura de diretórios em comparação com outros utilitários semelhantes a este.

Um olhar nos bastidores

Então, a partir do local do Site Path do painel, optei por carregar o diretório no Finder:

Isso me levou diretamente ao diretório de instalação do WordPress completo com a versão mais recente do twentytwentyonetema.

Dito isso, eu estava curioso para saber como outros aspectos do site foram configurados (como a lista de sites, o banco de dados e assim por diante). Então dei uma olhada no DevKinstadiretório e vi o seguinte:

• O kinstadiretório contém um único arquivo que lista todos os sites mantidos pelo software. Este é encontrado em sites.inique vou mostrar mais momentaneamente.
• O logsdiretório mostra informações relacionadas a qualquer coisa relacionada ao PHP, bem como erros do site (prefixados com o nome do site, como playground_access.log).
• No momento deste post, o privatediretório está vazio.
• O publicdiretório contém o playgrounddiretório que também incluirá outras instalações do WordPress que podem ser mantidas pelo DevKinsta.

Conforme mencionado anteriormente, uma olhada no sites.iniarquivo mostra que ele contém diretivas para cada site que o software mantém. Para esta demonstração específica, inclui o seguinte:

1[playground]
2domain=playground.local
3php_version=7.4
4is_multisite_subdir=1

Com base no que vejo aqui, espero ver valores ligeiramente múltiplos e ligeiramente diferentes com base no domínio local, na versão do PHP e na configuração multisite que seleciono ao configurar o site. Se houver mais, ainda não vi e se continuar a usar isso e for útil, farei referência aqui.

Carregando o Site

Neste ponto, estou pronto para dar uma olhada no site no front-end e na área de administração.

• Ao clicar em Abrir Site, consigo visualizar o site como se fosse um visitante. Ou seja, posso ver o front-end do site e também posso acessá-lo usando o https://playground.localendereço configurado na configuração.
• Ao clicar em WP Admin, estou indo para a área de administração. E isso é bom que eu salvei a senha durante a configuração porque requer que eu a insira aqui. Isso não é inesperado, mas não há outra maneira de acessá-lo [que consegui encontrar] além de redefinir a senha e acessar o e-mail do gerenciador de e-mail no DevKinsta.

Por fim, há uma opção para enviar para o staging que eu não tentei, pois não tenho uma conta de staging associada ao projeto específico configurado para esta postagem. Imagino que isso será útil para qualquer um que configurou uma nova conta Kinsta ou que por acaso derrube um de seus sites existentes (como este blog).

Uma visão rápida do uso da memória

Não tenho nada a comentar aqui além de compartilhar o que o Activity Monitor mostra ao carregar o DevKinsta:

Então faça disso o que você quiser para o seu caso de uso.

Pensamentos finais

No geral, estou – em uma palavra – satisfeito com o DevKinsta. Ele não traz nada de novo para a mesa, mas faz o que promete e o faz de uma maneira acessível a implementadores e desenvolvedores do WordPress.

Se você já usou outras ferramentas semelhantes, você se sentirá em casa. E se não, é fácil começar. Acho que esta versão estabelece uma base sólida e muito potencial para o desenvolvimento de recursos adicionais e excelentes.

Se eu pudesse pedir duas coisas, seriam:

1. Use arquitetura nativa em vez do Docker (embora eu entenda o motivo de usar o último),
2. Armazene as credenciais de login e mascare-as para o ambiente de desenvolvimento para que os usuários possam fazer login facilmente em seu site copiando a senha do painel do DevKinsta.

E se houvesse um bônus, acho que criar seus próprios complementos ou extensões também seria bom. Mas, novamente, esta é a primeira versão. E para isso, é polido e faz exatamente o que diz que vai fazer. E há algo a ser dito sem surpresas.

Fora isso, não há mais nada a dizer. Estou feliz com isso, provavelmente vou usá-lo para um próximo projeto que estou considerando, mas se você estiver satisfeito com sua configuração atual e não estiver no Kinsta, ficará bem com esse conjunto para cima, também.