Dovremmo ospitare il codice online?

Da professionista,

Se l'ufficio della tua azienda brucia, il codice è ancora sul server.

Se l'ufficio della tua azienda non viene bruciato, ma il server su cui si trova il tuo repository git FA, allora hai ancora una copia locale.

Se ospiterai il tuo repository sul tuo server nell'edificio aziendale della tua azienda (come faresti con un'unità di rete condivisa ...?), se l'ufficio dell'azienda brucia, perdi entrambi.

Naturalmente, hai ancora bisogno di backup come al solito ...

Sentiti libero di sostituire "brucia" con "viene infettato da ransomware".

In sostanza, la disponibilità è esaurita.

Come una truffa,

Dovresti condividere i tuoi file con la terza parte che ospiterà il tuo codice. Se hai segreti aziendali davvero grandi, questo potrebbe non essere permesso. Ad esempio, se disponi di un database contenente informazioni personali di cittadini europei, potresti non essere autorizzato a ospitare il tuo codice su una terza parte proveniente dagli Stati Uniti, perché sarebbero soggetti alla legge statunitense e quindi non potrebbero essere invocati a rispettare le leggi sulla privacy dell'UE. Anche se non è un problema legale, devi essere consapevole che la terza parte potrebbe essere corrotta nel dare via i tuoi file privati. Questo potrebbe essere molto negativo per la terza parte (penalizzazione della reputazione enorme), ma potrebbe accadere.

In sostanza, la riservatezza è in diminuzione.

Se sei d'accordo con la riservatezza del trading per la disponibilità, allora ospitare il tuo codice privato online con una terza parte è una buona idea. Altrimenti, non farlo. Potresti spiegare i compromessi per consentire al tuo capo di prendere una decisione intelligente, ma potresti sentire "no". Questo è quello che può succedere se dai una decisione a qualcuno. Se il tuo capo dice no, allora è quello. Non credo che convincere forzatamente il tuo capo sia una buona idea.

Ovviamente è una questione di fiducia nel fornitore e quanto apprezzi il tuo codice sorgente.

Tuttavia, penso sia chiaro che, almeno in passato, le persone hanno valutato il loro codice sorgente.

• per i prodotti di "automazione dei processi aziendali"; dove una squadra interna crea siti web e altri software specificamente per le esigenze del attività commerciale. Il valore di tale software per gli altri è generalmente molto basso.

• per software vendibile; è il binario che stai vendendo, e quello può essere copiati e violati senza accesso al codice sorgente.

In secondo luogo: dovresti anche considerare se memorizzare il tuo codice con una terza parte in realtà aumenta la tua esposizione al di sopra del suo livello attuale. In molti casi non sarà

• Ad esempio; se il tuo prodotto è un sito web senza codice back-end, il tuo il codice è già pubblico.
• Se il tuo codice compilato è distribuito, può essere decompilato.
• Se il tuo codice è un sito Web o un servizio e lo stai ospitando con un terzo. Quindi la terza parte può decompilare il tuo codice.
• Se si archiviano i backup con terzi, possono accedervi il tuo codice.

In breve, la maggior parte delle aziende moderne si fideranno di una varietà di terze parti con le loro attività quotidiane; anche le cose che sono vitali e uniche per loro.

Una parte di questo processo decisionale potrebbe essere un po 'test, prove ed errori. Fai un piccolo progetto e alcuni membri provano alcuni dei diversi siti. Questo dovrebbe coprire l'usabilità del team, ma ci sono altre considerazioni.

1. Infrastruttura corrente - Alcune società dispongono già di server, connessioni Internet, VPN e personale del personale con le competenze per ospitare i server, quindi alcuni dei costi e delle preoccupazioni possono essere assorbiti molto più facilmente. Una startup può essere più incline a utilizzare qualcosa come Github perché non deve fare questi tipi di investimenti e può essere presto operativo.
2. Budget: qui rientrano molti aspetti della # 1, ma possono esserci altre soluzioni con un prezzo elevato. Alcune aziende possono giustificare i costi. Ovviamente con un budget basso, molte opzioni vengono eliminate.
3. Distribuzione del team - Quando tutti lavorano fuori dallo stesso ufficio durante gli stessi orari, potresti non aver bisogno di github. Se il tuo file server non è troppo appesantito, metti Git su di esso.
4. Sicurezza: probabilmente è possibile trovare molti siti sicuri, ma le percezioni di sicurezza per alcuni clienti sono più importanti. Avere la propria rete di corazzate può essere la cosa giusta per ottenere la loro fiducia. I badge di sicurezza, gli scanner retinici e le guardie armate danno sicurezza ad alcuni clienti.
5. Addestramento - C'è molto di più di come usare l'app, ci sono le regole e le procedure che la tua azienda / squadra vuole mettere in atto. Avere un'idea di come si desidera fare le cose può guidare quali strumenti utilizzare. Attrarre altri membri del team diventa un po 'più facile se gli piace il modo in cui fai le cose.

Inizia a lavorare sull'intero processo di codifica e distribuzione. Più persone sono coinvolte in questo processo, meglio è. Non si desidera adottare una piattaforma di controllo del codice sorgente basata su determinati criteri per far sì che qualcuno nella gestione cambi tutto. "Questa cosa agile distribuita non funziona, quindi avremo bisogno che tutti inizino a lavorare dall'ufficio alle 8-7 a partire da lunedì, Okay."

Non sto dicendo necessariamente che non dovrebbe ospitare il repository della tua azienda nel cloud, ma personalmente ho riscontrato alcuni svantaggi e dolori con l'hosting del cloud.

Quanto è veloce e affidabile la tua connessione Internet?

Per me, questa è la più grande considerazione. Ad esempio, la mia azienda si trova in una bella zona rurale. Mentre le nostre velocità di intra sono molto veloci, le nostre velocità di inter sono al massimo lente, al contrario peggiore.

A seconda di quale VCS stai usando, alcuni dei dolori possono essere mitigati. I sistemi di controllo della versione distribuita, come Git, non sono così cattivi perché puoi ancora lavorare localmente. È anche possibile avviare un nuovo repository su un'unità di rete se è veramente necessario condividere codice con un collega. In confronto, non puoi davvero fare nessuna di queste cose con Team Foundation (nonostante l'intera area di lavoro locale).

Ma questo è solo il codice. C'è molto di più nel tuo repository cloud ospitato che solo il codice. E i tuoi oggetti di lavoro (caratteristiche / elenco di bug)? Che mi dici della tua documentazione (wiki)? Che mi dici della tua integrazione continua? Tutte queste cose saranno probabilmente ospitate nel cloud insieme al tuo codice. Se la tua connessione Internet non funziona, come funzionerai senza queste cose?

Gitlab fornisce una versione gratuita on-premise che probabilmente fornirà più del necessario per la tua squadra. Consiglio vivamente un'installazione on premise. Ridurrà considerevolmente i rischi.

What should we be considering in order to make this decision?

Dovresti considerare i lati negativi. Io (insieme ad altri) ho incoraggiato con successo il mio attuale datore di lavoro a smettere di ospitare i gioielli della proprietà intellettuale della corona dell'azienda su un repository privato di github. Non prendermi in errore; github è fantastico per il software open source.

Nel caso di software closed source, hai github.com (o qualche altra alternativa) firmare un accordo di non divulgazione (NDA) per non rilasciare il tuo codice sorgente al mondo? Buona fortuna!

A mio parere, è assolutamente pazzo rivelare i propri gioielli di proprietà intellettuale a un'altra entità fino a quando quell'altra entità non abbia firmato un accordo con la NDA. Stai pianificando di utilizzare un servizio come github che non firma NDA con i loro clienti. Offrono invece una promessa vaga sotto forma di un EULA molto lungo (contratto di licenza per l'utente finale).

Github si rende conto che questo può essere un problema significativo, e come risultato offrono a Github Enterprise un meccanismo per ospitare il codice sorgente (e altre cose private) sul proprio server.