modo tipico per condividere la connessione al database per il progetto open-source, senza rivelare troppo

Le best practice suggeriscono quanto segue:

1. Non commettere credenziali del database o altri dati sensibili sul controllo del codice sorgente. Mai. Metti quelli in un file (diciamo config.php ) che è esplicitamente escluso dal controllo del codice sorgente (attraverso .gitignore / .hgignore / ...) e fornisci un file segnaposto (ad esempio, config.dist.php ) invece che contiene solo credenziali fittizie; quindi nella guida all'installazione, chiedi alle persone di copiare questo file su config.php e inserisci le credenziali corrette.
2. Non concedere a nessuno l'accesso al server di produzione. Il database è l'ultimo dei tuoi dubbi: se consenti alle persone di caricare PHP arbitrario, potresti dare loro l'accesso alla shell e impedire a un hacker esperto di l'escalation della radice da lì confina con l'impossibile. Invece, avere persone eseguono le proprie installazioni private dell'applicazione. Fornire un esempio di configurazione di apache, php.ini e alcuni script per impostare un database di test (struttura e dati). Dovresti avere comunque un kit di installazione, anche se solo per la tua tranquillità. (Cosa succede se il tuo server di produzione si arresta in modo irreparabile? Avere un kit di installazione che ha dimostrato di funzionare significa poterlo reinstallare in qualsiasi momento, invece di dover trovare una soluzione di emergenza quando la stanza è già in fiamme.)
3. Esamina ogni singola riga di codice che va sul server di produzione o anche nella linea principale di sviluppo. Se si utilizza un sistema di controllo del codice sorgente distribuito, fare in modo che le persone lavorino sui propri cloni del repository principale e inviare richieste di pull per qualsiasi funzionalità che desiderano includere nella riga principale. Se sei ancora sul controllo del codice sorgente centralizzato, assegna a ciascun collaboratore il proprio ramo e imponi che solo tu debba unire il tronco. Verifica ogni unione prima di renderla definitiva.
4. Prova ogni versione prima di distribuirla. Questo dovrebbe essere ovvio, ma la realtà suggerisce il contrario. Inoltre, assicurati di utilizzare tag di rilascio; è il modo più semplice per assicurarsi che nessun commit extra si intrometta tra test e distribuzione (ad esempio, vuoi assicurarti che la versione che stai distribuendo sia la versione esatta che hai testato).

Per un po 'di frame di riferimento, considera di indossare due cappelli: il cappello del manutentore del codice e il cappello utente principale. Come manutentore del codice, tieni sotto controllo il controllo del codice sorgente e tutto ciò che vi viene fornito; come utente principale, si installa il prodotto su un server e lo si apre al pubblico. Struttura l'intero progetto in un modo che ti permetta di passare uno di quei cappelli a qualcun altro in qualsiasi momento senza influire sul tuo lavoro sotto l'altro. Ad un certo punto, potresti voler condividere l'onere di questi doveri e, quando ciò accadrà, sarà utile se dovrai fidarti delle persone con il repository principale o del server di produzione, ma non entrambi .

Perché altri sviluppatori vogliono lavorare sul server di produzione? Dovrebbero lavorare su macchine proprie o su macchine non di produzione condivise dove possono fare qualsiasi cosa.

Inoltre, tutte le configurazioni correlate dovrebbero essere nei file di configurazione. Nessuna configurazione del genere dovrebbe essere nel codice sorgente.