zzugab/juice-shop-with-kubeadm-and-tfDeploy automatico di OWASP Juice Shop su Kubernetes utilizzando kubeadm e Terraform, con scansione integrata delle vulnerabilità Trivy per pipeline DevSecOps.
Per facilitare l'inizio con GitLab, ecco un elenco di passaggi successivi consigliati.
Già un professionista? Modifica questo README.md e personalizzalo. Vuoi semplificare? Usa il template in fondo!
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
Usa l'integrazione continua integrata in GitLab.
Quando sei pronto per rendere questo README tuo, modifica questo file e usa il pratico template qui sotto (o sentiti libero di strutturarlo come preferisci - questo è solo un punto di partenza!). Grazie a makeareadme.com per questo template.
Ogni progetto è diverso, quindi considera quali di queste sezioni si applicano al tuo. Le sezioni usate nel template sono suggerimenti per la maggior parte dei progetti open source. Tieni anche presente che mentre un README può essere troppo lungo e dettagliato, troppo lungo è meglio che troppo corto. Se pensi che il tuo README sia troppo lungo, considera di utilizzare un'altra forma di documentazione piuttosto che tagliare via informazioni.
Scegli un nome autoesplicativo per il tuo progetto.
Fai sapere alle persone cosa può fare specificamente il tuo progetto. Fornisci contesto e aggiungi un collegamento a qualsiasi riferimento che i visitatori potrebbero non conoscere. Un elenco di Funzionalità o una sottosezione di Contesto può essere aggiunta qui. Se ci sono alternative al tuo progetto, questo è un buon posto per elencare i fattori differenzianti.
Su alcuni README, potresti vedere piccole immagini che veicolano metadati, come se tutti i test stanno passando per il progetto. Puoi usare Shields per aggiungerne alcuni al tuo README. Molti servizi hanno anche istruzioni per aggiungere un badge.
A seconda di cosa stai realizzando, può essere una buona idea includere screenshot o persino un video (vedrai spesso GIF piuttosto che video reali). Strumenti come ttygif possono aiutare, ma dai un'occhiata ad Asciinema per un metodo più sofisticato.
All'interno di un particolare ecosistema, potrebbe esserci un modo comune per installare le cose, come l'uso di Yarn, NuGet o Homebrew. Tuttavia, considera la possibilità che chi sta leggendo il tuo README sia un principiante e desideri più indicazioni. Elencare passaggi specifici aiuta a rimuovere l'ambiguità e fa sì che le persone utilizzino il tuo progetto il più rapidamente possibile. Se funziona solo in un contesto specifico come una particolare versione di linguaggio di programmazione o sistema operativo o ha dipendenze che devono essere installate manualmente, aggiungi anche una sottosezione Requisiti.
Usa gli esempi liberamente e mostra l'output previsto se puoi. È utile avere inline il più piccolo esempio di utilizzo che puoi dimostrare, fornendo collegamenti a esempi più sofisticati se sono troppo lunghi per essere inclusi ragionevolmente nel README.
Dì alle persone dove possono andare per chiedere aiuto. Può essere qualsiasi combinazione di un issue tracker, una chat room, un indirizzo email, ecc.
Se hai idee per release future, è una buona idea elencarle nel README.
Indica se sei aperto a contributi e quali sono i tuoi requisiti per accettarli.
Per le persone che vogliono apportare modifiche al tuo progetto, è utile avere della documentazione su come iniziare. Forse c'è uno script che dovrebbero eseguire o alcune variabili d'ambiente che devono impostare. Rendi espliciti questi passaggi. Queste istruzioni potrebbero essere utili anche al tuo futuro io.
Puoi anche documentare i comandi per lintare il codice o eseguire test. Questi passaggi aiutano a garantire un'alta qualità del codice e riducono la probabilità che le modifiche rompano inavvertitamente qualcosa. Avere istruzioni per eseguire i test è particolarmente utile se richiede una configurazione esterna, come avviare un server Selenium per test in un browser.
Mostra il tuo apprezzamento a coloro che hanno contribuito al progetto.
Per i progetti open source, indica come è concesso in licenza.
Se hai finito l'energia o il tempo per il tuo progetto, metti una nota all'inizio del README dicendo che lo sviluppo è rallentato o si è fermato completamente. Qualcuno potrebbe scegliere di forkare il tuo progetto o offrirsi volontario come manutentore o proprietario, permettendo al tuo progetto di continuare. Puoi anche fare una richiesta esplicita di manutentori.