Quali motivi ci sono per non utilizzare un servizio di controllo versioni di terze parti?

Evita di utilizzare un sistema di controllo versione ospitato da terze parti quando:

1. Il codice è sotto NDA o altrimenti ha obblighi contrattuali o legali che il provider di hosting non può o non imporrà. Ad esempio, il codice ospitato esternamente potrebbe presentare problemi con la certificazione Common Criteria (potrebbe trattarsi o meno di un problema, ma il controllo del codice sorgente è stato discusso nei progetti in cui sono stato coinvolto).
2. Il codice contiene brevetti non divulgati, segreti commerciali o altra proprietà intellettuale che il fornitore di hosting non può o non vuole proteggere.

Altre cose da considerare quando si utilizza un provider di hosting di terze parti:

1. Il provider di hosting supporta il sistema di controllo della versione che stai utilizzando? La conversione è possibile ma spesso complessa e difficile. (Questo è stato menzionato nella domanda ma è incluso qui per completezza)
2. Come ti vengono addebitati per il servizio? Ci sono limiti o soglie come limiti di dimensione del repository, limiti di larghezza di banda o limitazione, limiti utente? La maggior parte dei provider è relativamente economica, ma assicurati di calcolare quanto costerà effettivamente prima di utilizzare il servizio.
3. Il provider di hosting si aggiorna frequentemente alle versioni più recenti? In caso contrario, sono disponibili funzionalità nelle versioni più recenti? Se lo fanno, ci sono incompatibilità tra la versione più recente e la versione che stai usando ora?
4. Il provider di hosting soddisfa i requisiti di uptime o larghezza di banda? Se il codice sorgente è inaccessibile quando ne hai bisogno, quali sono le opzioni legali per recuperare i costi? La maggior parte dei sistemi fornisce poche garanzie.
5. Il provider di hosting memorizza il codice sorgente in un paese o giurisdizione in cui le leggi possono consentire ad altri l'accesso? Molti provider di hosting esternalizzano il loro storage e server a un provider di cloud IaaS come Amazon, ma vale comunque la pena di porre la domanda.
6. Il provider di hosting fornisce registri di controllo degli accessi, non solo modifiche?
7. Come crei e gestisci utenti che hanno accesso al codice sorgente? Puoi delegare questo ad altre persone nell'organizzazione? Puoi accedere ai log di audit della gestione degli utenti?
8. Il provider di hosting fornisce o applica un'autenticazione strong o a più fattori?
9. Il provider impone la comunicazione crittografata, ad es. SSL o SSH? È possibile accedere a eventuali certificati o chiavi laterali specifici del cliente, se necessario?
10. Come si "onboard" qualsiasi codice sorgente esistente? Puoi caricare o importare la cronologia?
11. Quando cessi di essere cliente del fornitore di servizi di hosting, puoi accedere alla cronologia del tuo codice sorgente? Se sì, come e per quanto tempo? Cosa succede se l'hosting provider fallisce o si fonde con il tuo concorrente?
12. Come cambieranno le tue esigenze nel tempo? Hai probabilmente bisogno di più o meno spazio, utenti o repository di quello che hai ora? Il fornitore può gestire queste modifiche?
13. La tua organizzazione avrà bisogno di più larghezza di banda per far fronte all'aumento di flusso e uscita di dati?
14. Il sistema di controllo del codice sorgente esistente on-premise si integra con un servizio di autenticazione come Active Directory? L'utilizzo di un provider di hosting di terze parti di solito significa che gli sviluppatori devono ricordare un'altra serie di credenziali.

Ricorda anche che i fornitori di hosting di terze parti non sono il "punto d'argento" per la ridondanza. Possono essere ottimi come backup aggiuntivi facilmente accessibili, ma pochi provider di hosting garantiranno i backup, almeno non senza pagare di più.

Detto questo, i provider di hosting di terze parti possono essere grandi, in particolare per una forza lavoro distribuita, dal momento che possono lavorare sul codice sorgente senza richiedere l'accesso VPN ed è un server in meno che deve essere amministrato.

I servizi esterni non sono sempre stabili, a volte vanno giù. Github ha avuto molta sfortuna con i tempi di inattività negli ultimi mesi, fuori per qualche ora alla volta.

Il codice potrebbe essere privato. Se hai una NDA o qualcosa che non condividi codice con nessuno, compresi i dipendenti di servizi esterni, che possono accedere al codice nei repository anche dopo che sono stati cancellati.

Se hai un numero elevato di repository (per Github) o un numero elevato di collaboratori (per Bitbucket) può diventare piuttosto costoso ospitarli nel cloud. La maggior parte delle agenzie che lavorano con i clienti probabilmente si imbattono in questa limitazione. Molto, molto meno costoso tenere un PC sotto la scrivania di qualcuno con git o svn installato su di esso.

È proprio quello che riesco a pensare, in cima alla mia testa.