zzugab/juice-shop-with-kubeadm-and-tfImplantação automatizada do OWASP Juice Shop no Kubernetes usando kubeadm e Terraform, com varredura integrada de vulnerabilidades Trivy para pipelines DevSecOps.
Para facilitar o início com o GitLab, aqui está uma lista de próximos passos recomendados.
Já é um profissional? Basta editar este README.md e torná-lo seu. Quer facilitar? Use o modelo no final!
cd existing_repo
git remote add origin https://gitlab.com/zzugab/juice-shop-with-kubeadm-and-tf.git
git branch -M main
git push -uf origin main
Use a integração contínua integrada no GitLab.
Quando estiver pronto para tornar este README seu, basta editar este arquivo e usar o prático modelo abaixo (ou sinta-se à vontade para estruturá-lo como quiser - este é apenas um ponto de partida!). Agradecimentos a makeareadme.com por este modelo.
Cada projeto é diferente, então considere quais destas seções se aplicam ao seu. As seções usadas no modelo são sugestões para a maioria dos projetos de código aberto. Tenha também em mente que, embora um README possa ser muito longo e detalhado, muito longo é melhor do que muito curto. Se você acha que seu README é muito longo, considere utilizar outra forma de documentação em vez de cortar informações.
Escolha um nome autoexplicativo para o seu projeto.
Deixe as pessoas saberem o que seu projeto pode fazer especificamente. Forneça contexto e adicione um link a qualquer referência que os visitantes possam não conhecer. Uma lista de Recursos ou uma subseção de Histórico também pode ser adicionada aqui. Se houver alternativas ao seu projeto, este é um bom lugar para listar fatores diferenciadores.
Em alguns READMEs, você pode ver pequenas imagens que transmitem metadados, como se todos os testes estão passando para o projeto. Você pode usar Shields para adicionar alguns ao seu README. Muitos serviços também têm instruções para adicionar um selo.
Dependendo do que você está fazendo, pode ser uma boa ideia incluir capturas de tela ou até mesmo um vídeo (você verá frequentemente GIFs em vez de vídeos reais). Ferramentas como ttygif podem ajudar, mas confira Asciinema para um método mais sofisticado.
Dentro de um ecossistema específico, pode haver uma maneira comum de instalar coisas, como usar Yarn, NuGet ou Homebrew. No entanto, considere a possibilidade de que quem está lendo seu README seja um novato e gostaria de mais orientação. Listar etapas específicas ajuda a remover ambiguidades e faz com que as pessoas usem seu projeto o mais rápido possível. Se ele só funciona em um contexto específico, como uma versão de linguagem de programação ou sistema operacional específicos, ou tem dependências que precisam ser instaladas manualmente, adicione também uma subseção de Requisitos.
Use exemplos livremente e mostre a saída esperada se puder. É útil ter inline o menor exemplo de uso que você pode demonstrar, enquanto fornece links para exemplos mais sofisticados se eles forem muito longos para incluir razoavelmente no README.
Diga às pessoas onde elas podem buscar ajuda. Pode ser qualquer combinação de um rastreador de issues, uma sala de bate-papo, um endereço de e-mail, etc.
Se você tem ideias para versões futuras, é uma boa ideia listá-las no README.
Declare se você está aberto a contribuições e quais são seus requisitos para aceitá-las.
Para pessoas que desejam fazer mudanças no seu projeto, é útil ter alguma documentação sobre como começar. Talvez haja um script que elas devam executar ou algumas variáveis de ambiente que precisem definir. Torne essas etapas explícitas. Essas instruções também podem ser úteis para você no futuro.
Você também pode documentar comandos para lint do código ou executar testes. Essas etapas ajudam a garantir alta qualidade do código e reduzem a probabilidade de que as mudanças inadvertidamente quebrem algo. Ter instruções para executar testes é especialmente útil se requer configuração externa, como iniciar um servidor Selenium para testar em um navegador.
Mostre sua gratidão àqueles que contribuíram para o projeto.
Para projetos de código aberto, diga como é licenciado.
Se você ficou sem energia ou tempo para o seu projeto, coloque uma nota no topo do README dizendo que o desenvolvimento desacelerou ou parou completamente. Alguém pode optar por bifurcar seu projeto ou se voluntariar como mantenedor ou proprietário, permitindo que seu projeto continue. Você também pode fazer um pedido explícito por mantenedores.