Dovremmo ospitare codice online?


22

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?


13
Nota che non è necessario archiviare il codice nel cloud per usare github. Vendono un prodotto aziendale
Gort the Robot,

1
@StevenBurnap sì ... per 10 volte il prezzo del pacchetto Organizzazione . =)
Mathieu Guindon il

12
Inoltre, non è necessario Github per usare git
Harrison Paine,

6
Tieni presente che non si tratta solo di codice. È comune per gli sviluppatori impegnare accidentalmente cose come password e chiavi SSL.
Nate CK,

5
Sono sinceramente stupito che nessuno abbia menzionato GitLab Community Edition che, a differenza di GitHub , è in realtà open source . Non è necessario archiviare il codice nel cloud o ottenere software proprietario per utilizzare GitLab. (@StevenBurnap)
Wildcard il

Risposte:


24

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.


Dal momento che questa è una domanda di lista, un'altra truffa da aggiungere alla tua lista: cosa succede se l'organizzazione di hosting si avvicina a Google Code?
David Hammen,

@DavidHammen Se il server si esaurisce, hai una copia locale ... ma ... immagino che ci sia un problema con la manutenzione non pianificata ...? Penso che questo punto sia disponibile da entrambe le parti; se si ospita il proprio server, sarà più inattivo, se qualcun altro ospita il server potrebbe essere inattivo quando è scomodo. In questo caso, github potrebbe andare male, ma anche il tuo server. Penso che sia meno probabile che la terza parte scompaia, in questo caso.
Pimgd,

9
Nota che se stai usando git, ogni sviluppatore avrà una copia del repository. (Meno le filiali private.)
Gort il robot il

3
@DavidHammen Quindi, proprio come se i server del servizio fossero stati bruciati, hai ancora una copia locale. E poi puoi scegliere di passare a un servizio alternativo o portare tutto in casa.
8bittree,

3
@ njzk2 a causa della rete a bassa latenza? O perché sei una piccola azienda? Forse la tua internet è una cazzata totale e vorresti avere un rapido accesso ai tuoi file ...
Pimgd

11

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.


3

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."


2

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.


1
È incredibile come la mia opinione su questo cambi ora che lavoro in città con una connessione Internet affidabile. Se la tua connessione Internet è affidabile, non c'è motivo di pagare i costi per mantenerli su server prem.
RubberDuck

1

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.


4
Quindi ... per un semplice sito Web del produttore dovrebbe andare bene, giusto? La "proprietà intellettuale della corona" dell'azienda riguarda più ciò che stiamo producendo che il codice che utilizziamo per promuoverlo.
Mathieu Guindon,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.