Um indie hacker é alguém que constrói e opera negócios de forma independente, muitas vezes focando em startups de tecnologia ou empreendimentos digitais.
Eles geralmente preferem manter o controle total sobre seus projetos, evitando investimentos externos e buscando criar fontes de renda sustentáveis por conta própria.
O termo "indie" vem de "independente", enquanto "hacker" refere-se à mentalidade de solucionador de problemas e à habilidade em criar soluções técnicas. Os indie hackers frequentemente compartilham suas experiências, aprendizados e estratégias dentro da comunidade, buscando colaboração e feedback para melhorar seus empreendimentos, por isso começarei uma série de posts sobre sugestões e dicas de experiências passadas que tive que podem ser úteis para outras pessoas ou outros negócios.
E o primeiro assunto a ser abordado são automatizações que podemos fazer com o Github Actions pra facilitar nossa vida e otimizar nosso tempo que pode ser feito diretamente no repositório do seu projeto de forma personalizada.
Podemos definir diversos tipos de trabalho pra diferentes ações, a abordada no post é pra fazer o code review do código, pois é de extrema importância manter a qualidade do código e manter padrões e as melhores práticas, mesmo que trabalhando sozinho, o que a maioria dos indie hackers fazem, ou em equipes grandes.
Com o Github Actions você pode definir um fluxo de trabalho a partir de um evento, como abertura de um PR por exemplo. Os fluxos de trabalho são definidos no diretório .github/workflows do repositório, através de arquivos com a extensão .yml.
Cada fluxo de trabalho definido no arquivo .yml tem uma ação que é executada por um único executor, sendo um script shell em uma máquina virtual provisionada em diversos sistemas operacionais diferentes.
O exemplo que darei abaixo é estruturando um .yml de acordo com a documentação, usando a linguagem PHP através do phplint, porém pode ser facilmente utilizado com outras linguagens, pois o Github Actions Marketplace possuí uma loja de repositórios de ações e deploys já prontos.
Vamos seprar em duas partes, na parte da identificação do fluxo de trabalho e nos trabalhos em sí.
// Opcional - O nome do fluxo de trabalho conforme aparecerá na guia "Ações" do repositório GitHub.
name: PHP Linting
// Especifica o evento para este fluxo de trabalho. Este exemplo usa o evento push, portanto, uma execução de fluxo de trabalho é acionada sempre que alguém envia uma alteração para o repositório ou mescla uma solicitação na branch especificada ou não.
on:
pull_request:
branches: ["master"]
// É usado para definir quais recursos externos à ação estão sendo acessados e como esses acessos são autorizados. Por exemplo, se uma ação precisa acessar o repositório onde está sendo executada, pode precisar de permissões para ler nos arquivos do repositório. Da mesma forma, se a ação precisa interagir com serviços externos, como fazer chamadas de API para serviços de nuvem, pode precisar de permissões específicas para isso.
permissions:
contents: read
Agora na definição dos trabalhos, temos a seguinte estrutura.
// Agrupa todos os trabalhos executados no fluxo de trabalho.
jobs:
build:
// Configura o trabalho para ser executado na versão mais recente de um executor Ubuntu Linux. Isso significa que o trabalho será executado em uma nova máquina virtual hospedada pelo GitHub.
name: PHP Lint
runs-on: ubuntu-latest
steps:
// A palavra-chave uses especifica que esta etapa executará a v3 da ação actions/checkout. Esta é uma ação que faz clone do seu repositório no executor, permitindo que você execute scripts ou outras ações em seu código (como ferramentas de construção e teste). Você deve usar a ação de checkout sempre que seu fluxo de trabalho usar o código do repositório.
- name: Copying test repository
uses: actions/checkout@v3
// A palavra-chave uses especifica que esta etapa executará a v8 da ação do php-lint, que irá ajudar os desenvolvedores a detectar os erros sempre que o pull request receber atualizações.
- name: Run php lint
uses: StephaneBour/[email protected]
// A palavra-chave uses especifica que esta etapa executará a v1 da ação do review dog, que irá ajudar os desenvolvedores a detectar e corrigir erros de codificação adicionando comentários no pull requests.
- name: Run php check code with reviewdog
uses: GeneaLabs/[email protected]
with:
level: "error"
fail_on_error: "true"
phpstan_level: 4
reporter: "github-pr-review"
target_directory: "./"
O resultado do nosso fluxo de trabalho seria algo parecido com isso:
A revisão de código pode ajudar a identificar potenciais vulnerabilidades de segurança no código antes que ele seja implantado em produção. Isso é especialmente importante em ambientes onde a segurança é uma preocupação primordial.
Após o início de uma execução de fluxo de trabalho, você pode ver um gráfico de visualização do progresso da execução e visualizar a atividade de cada etapa em GitHub.
O GitHub Actions pode ajudá-lo a automatizar quase todos os aspectos dos processos de desenvolvimento da sua aplicação. Pronto para começar?
Fontes
Github Actions - Docs