Dovremmo ospitare codice online?

Stiamo cercando una buona soluzione di controllo del codice sorgente e di gestione dei progetti sul mio posto di lavoro e ho suggerito di creare un'organizzazione GitHub e repository privati. Adoro GitHub per molte ragioni, ma non si tratta di GitHub (in effetti i miei colleghi presenteranno punti a favore delle piattaforme concorrenti) - si tratta di archiviare il nostro codice privato online .

Sto cercando di capire se questa è una buona idea o no. Sembra sicuramente vantaggioso perché elimina la necessità di costi del server (almeno direttamente) e semplifica anche la ricerca del codice (tutto è online).

Tuttavia il nostro team è indeciso e mi porta alla mia domanda, cosa dovremmo considerare per prendere questa decisione?

Come professionista,

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

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

Se si ospita il repository sul server nell'edificio della propria azienda (come si farebbe con un'unità condivisa in rete ...?), Se l'ufficio della società si brucia, si perdono entrambi.

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

Sentiti libero di sostituire "burns down" con "viene infettato da ransomware".

Fondamentalmente, la disponibilità è aumentata.

Come truffatore,

Dovresti condividere i tuoi file con terze parti che ospiteranno 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, poiché sarebbero soggetti alla legge degli Stati Uniti e quindi non ci si può fare affidamento su rispettare le leggi sulla privacy dell'UE. Anche se non si tratta di un problema legale, dovresti essere consapevole che la terza parte potrebbe essere corrotta nel dare via i tuoi file privati. Probabilmente questo sarebbe davvero un male per la terza parte (enorme penalità di reputazione), ma potrebbe accadere.

Fondamentalmente, la riservatezza è in calo.

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

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

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

• Per i prodotti di "automazione dei processi aziendali"; dove un team interno crea siti Web e altri software appositamente per le esigenze dell'azienda. Il valore di quel software per gli altri è generalmente molto basso.

• Per software vendibile; è il binario che stai vendendo e che può essere copiato e hackerato senza accedere al codice sorgente.

In secondo luogo: dovresti anche considerare se archiviare il tuo codice con una terza parte aumenta effettivamente l'esposizione al di sopra del suo livello attuale. In molti casi non lo farà

• Per esempio; se il tuo prodotto è un sito Web senza codice back-end, il tuo codice è già pubblico.
• Se il codice compilato viene distribuito, può essere decompilato.
• Se il tuo codice è un sito Web o un servizio e lo stai ospitando con una terza parte. Quindi la terza parte può decompilare il codice.
• Se memorizzi i tuoi backup con terze parti, questi hanno accesso al tuo codice.

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

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

1. Infrastruttura attuale: alcune aziende dispongono già di server, connessioni Internet, VPN e personale con le competenze necessarie per ospitare server, quindi alcuni dei costi e delle preoccupazioni possono essere assorbiti molto più facilmente. Una startup potrebbe essere più propensa a utilizzare qualcosa come Github perché non deve effettuare questo tipo di investimenti e può iniziare e funzionare prima.
2. Budget - Molti aspetti del n. 1 rientrano qui, ma ci possono essere altre soluzioni con un prezzo elevato. Alcune aziende possono giustificare i costi. Ovviamente con un budget ridotto, vengono eliminate molte opzioni.
3. Distribuzione del team - Quando tutti lavorano fuori dallo stesso ufficio durante le stesse ore, potrebbe non essere necessario Github. Se il tuo file server non è troppo gravoso, mettici sopra Git.
4. Sicurezza: probabilmente puoi trovare molti siti sicuri, ma le percezioni della sicurezza per alcuni clienti sono più importanti. Avere la tua rete corazzata può essere la cosa giusta per guadagnare la loro fiducia. Distintivi di sicurezza, scanner retinici e guardie armate gridano sicurezza ad alcuni clienti.
5. Formazione: c'è molto altro oltre al semplice utilizzo dell'app, ci sono le regole e le procedure che la tua azienda / squadra vuole mettere in atto. Avere un'idea di come vuoi fare le cose può guidare quali strumenti usare. Attirare altri membri del team diventa un po 'più semplice se a loro piace il modo in cui fai le cose.

Inizia a lavorare attraverso l'intero processo di codifica e consegna. Più persone sono coinvolte in questo processo, meglio è. Non si desidera adottare una piattaforma di controllo del codice sorgente basata su determinati criteri solo per consentire a qualcuno nella gestione di modificare 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 necessariamente dicendo che non dovresti ospitare il repository della tua azienda nel cloud, ma ho sperimentato personalmente alcuni svantaggi e dolori con l'hosting cloud.

Quanto è veloce e affidabile la tua connessione Internet?

Per me, questa è l'unica considerazione più grande. Ad esempio, la mia azienda si trova in una bella zona rurale. Mentre i nostri intra velocità -net sono velocissimo, le nostre interrelazioni velocità -net sono lenti nella migliore delle ipotesi, flakey addirittura nel peggiore dei casi.

A seconda di quale VCS stai usando, parte del dolore può essere mitigato. I sistemi di controllo della versione distribuita, come Git, non sono così male perché puoi ancora lavorare localmente. Puoi persino avviare un nuovo repository su un'unità di rete se hai davvero bisogno di condividere un po 'di 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 repository ospitato sul cloud oltre al semplice codice. E i tuoi oggetti di lavoro (caratteristiche / elenco bug)? E la tua documentazione (wiki)? E la tua build a integrazione continua? Tutte queste cose saranno probabilmente ospitate nel cloud insieme al tuo codice. Se la tua connessione Internet si interrompe, come lavorerai senza queste cose?

Gitlab offre una versione gratuita on-premise che probabilmente fornirà più di quanto il tuo team abbia bisogno. Consiglio vivamente un'installazione locale. Ridurrà considerevolmente i rischi.

Cosa dovremmo considerare per prendere questa decisione?

Dovresti considerare gli aspetti 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 su un repo privato di github. Non fraintendermi; github è fantastico per il software open source.

Nel caso di software chiuso, hai fatto firmare a github.com (o qualche alternativa) un accordo di non divulgazione (NDA) per non rilasciare il tuo codice sorgente nel mondo? Buona fortuna!

A mio avviso, è assolutamente folle divulgare i gioielli della proprietà intellettuale di una corona a qualche altra entità fino a quando quest'ultima non ha firmato un accordo di riservatezza con te. Stai pensando di utilizzare un servizio come github che non firma accordi di riservatezza con i loro clienti. Offrono invece una vaga promessa sotto forma di un EULA (accordo di licenza con l'utente finale) molto lungo.

Github stesso si rende conto che questo può essere un problema significativo e, di conseguenza, offre Github Enterprise come meccanismo per l'hosting del codice sorgente (e di altre cose private) sul proprio server.