Devrions-nous héberger du code en ligne?

Nous recherchons une bonne solution de contrôle de source et de gestion de projet sur mon lieu de travail et j'ai suggéré de créer une organisation GitHub et des référentiels privés. J'adore GitHub pour de nombreuses raisons, mais il ne s'agit pas de GitHub (en fait, mes collègues vont présenter des points en faveur de plates-formes concurrentes) - il s'agit de stocker notre code privé en ligne .

J'essaie de comprendre si c'est une bonne idée ou non. Cela semble définitivement avantageux car il supprime le besoin de coûts de serveur (au moins directement) et facilite également la recherche de code (tout est en ligne).

Cependant, notre équipe est indécise et m'amène à ma question, que devons-nous considérer pour prendre cette décision?

En tant que pro,

Si le bureau de votre entreprise brûle, le code est toujours sur le serveur.

Si le bureau de votre entreprise ne brûle pas, mais que le serveur sur lequel se trouve votre référentiel git le fait, vous avez toujours une copie locale.

Si vous hébergez votre référentiel sur votre serveur dans l'immeuble de bureaux de votre entreprise (comme vous le feriez avec un lecteur partagé réseau ...?), Alors si le bureau de l'entreprise brûle, vous perdez les deux.

Bien sûr, vous avez toujours besoin de sauvegardes comme d'habitude ...

N'hésitez pas à remplacer «burns down» par «est infecté par un ransomware».

Fondamentalement, la disponibilité est en hausse.

En con,

Vous devez partager vos fichiers avec le tiers qui hébergera votre code. Si vous avez de très gros secrets d'entreprise, cela pourrait ne pas être autorisé. Par exemple, si vous avez une base de données contenant des informations personnelles de citoyens européens, vous pourriez ne pas être autorisé à héberger votre code sur un tiers des États-Unis - car ils seraient soumis à la loi américaine et ne pourraient donc pas être invoqués pour respecter les lois de l'UE sur la confidentialité. Même si ce n'est pas un problème juridique, vous devez savoir que le tiers pourrait être corrompu pour donner vos fichiers privés. Ce serait probablement très mauvais pour le tiers (énorme pénalité de réputation), mais cela pourrait arriver.

Fondamentalement, la confidentialité est en baisse.

Si vous êtes d'accord avec l'échange de confidentialité pour la disponibilité, l'hébergement de votre code privé en ligne avec un tiers est une bonne idée. Sinon, non. Vous pourriez expliquer les compromis pour permettre à votre patron de prendre une décision intelligente - mais vous pourriez entendre «non». C'est ce qui peut arriver si vous donnez une décision à quelqu'un. Si votre patron dit non, c'est tout. Je ne pense pas que convaincre de force votre patron soit une très bonne idée.

Évidemment, c'est une question de confiance dans le fournisseur et dans quelle mesure vous appréciez votre code source.

Cependant, je pense qu'il est clair que, au moins dans le passé, les gens ont surévalué leur code source.

• Pour les produits «d'automatisation des processus métier»; où une équipe interne crée des sites Web et d'autres logiciels spécifiquement pour les besoins de l'entreprise. La valeur de ce logiciel pour d'autres personnes est généralement très faible.

• Pour les logiciels vendables; c'est le binaire que vous vendez, et qui peut être copié et piraté sans accès au code source.

Deuxièmement: vous devez également déterminer si le stockage de votre code avec un tiers augmente réellement votre exposition au-dessus de son niveau actuel. Dans de nombreux cas,

• Par exemple; si votre produit est un site Web sans code backend, votre code est déjà public.
• Si votre code compilé est distribué, il peut être décompilé.
• Si votre code est un site Web ou un service et que vous l'hébergez avec un tiers. Ensuite, le tiers peut décompiler votre code.
• Si vous stockez vos sauvegardes avec un tiers, il a accès à votre code.

En bref, la plupart des entreprises modernes feront confiance à divers tiers pour leurs activités quotidiennes; même des choses qui leur sont vitales et uniques.

Une partie de ce processus de décision pourrait consister en quelques tests, essais et erreurs. Prenez un petit projet et demandez à quelques membres d'essayer certains des différents sites. Cela devrait couvrir l'utilisabilité par l'équipe, mais il y a d'autres considérations.

1. Infrastructure actuelle - Certaines entreprises ont déjà des serveurs, des connexions Internet, un VPN et du personnel ayant les compétences nécessaires pour héberger des serveurs, de sorte que certains des coûts et des préoccupations peuvent être absorbés beaucoup plus facilement. Une startup peut être plus encline à utiliser quelque chose comme Github car elle n'a pas à faire ce type d'investissements et peut être opérationnelle plus tôt.
2. Budget - De nombreux aspects de # 1 relèveront ici, mais il peut y avoir d'autres solutions avec un prix élevé. Certaines entreprises peuvent justifier les coûts. Évidemment avec un petit budget, de nombreuses options sont éliminées.
3. Distribution d'équipe - Lorsque tout le monde travaille dans le même bureau pendant les mêmes heures, vous n'avez peut-être pas besoin de github. Si votre serveur de fichiers n'est pas trop chargé, mettez simplement Git dessus.
4. Sécurité - Vous pouvez probablement trouver de nombreux sites sécurisés, mais les perceptions de sécurité pour certains clients sont plus importantes. Avoir votre propre réseau à toute épreuve peut être la bonne chose pour gagner leur confiance. Les badges de sécurité, les scanners rétiniens et les gardes armés ne font que crier la sécurité à certains clients.
5. Formation - Il n'y a pas que la façon d'utiliser l'application, il y a les règles et procédures que votre entreprise / équipe veut mettre en place. Avoir une idée de la façon dont vous voulez faire les choses peut déterminer les outils à utiliser. Attirer des membres supplémentaires de l'équipe devient un peu plus facile s'ils aiment la façon dont vous faites les choses.

Commencez à travailler tout au long du processus de codage et de livraison. Plus il y a de personnes impliquées dans ce processus, mieux c'est. Vous ne voulez pas adopter une plate-forme de contrôle de source basée sur certains critères uniquement pour qu'un membre de la direction change tout. "Cette chose agile distribuée ne fonctionne pas, nous aurons donc besoin que tout le monde commence à travailler depuis le bureau à 8-7 à partir de lundi, d'accord."

Je ne dis pas nécessairement que vous ne devriez pas héberger le référentiel de votre entreprise dans le cloud, mais j'ai personnellement rencontré des inconvénients et des difficultés avec l'hébergement cloud.

Quelle est la vitesse et la fiabilité de votre connexion Internet?

Pour moi, c'est la plus grande considération. Par exemple, mon entreprise est située dans une jolie zone rurale. Alors que nos vitesses intra- réseau sont extrêmement rapides, nos vitesses inter- réseaux sont lentes au mieux, carrément floconneuses au pire.

Selon le VCS que vous utilisez, une partie de la douleur peut être atténuée. Les systèmes de contrôle de version distribués, comme Git, ne sont pas si mauvais parce que vous pouvez toujours travailler localement. Vous pouvez même initier un nouveau dépôt sur un lecteur réseau si vous avez vraiment besoin de partager du code avec un collègue. En comparaison, vous ne pouvez pas vraiment faire l'une de ces choses avec Team Foundation (malgré tout l'espace de travail local).

Mais c'est juste le code. Votre référentiel hébergé dans le cloud comporte bien plus que le simple code. Qu'en est-il de vos éléments de travail (fonctionnalités / liste de bogues)? Et votre documentation (wiki)? Qu'en est-il de votre build d'intégration continue? Toutes ces choses seront probablement également hébergées dans le cloud à côté de votre code. Si votre connexion Internet tombe en panne, comment allez-vous travailler sans ces choses?

Gitlab fournit une version gratuite sur site qui fournira probablement plus que les besoins de votre équipe. Je recommande fortement une installation sur site. Cela réduira considérablement les risques.

Que devrions-nous considérer pour prendre cette décision?

Vous devriez considérer les inconvénients. J'ai (avec d'autres) encouragé avec succès mon employeur actuel à cesser d'héberger les joyaux de la propriété intellectuelle de la société sur une mise en pension privée de github. Ne vous méprenez pas; github est fantastique pour les logiciels open source.

Dans le cas d'un logiciel à source fermée, avez-vous demandé à github.com (ou une autre alternative) de signer un accord de non-divulgation (NDA) pour ne pas divulguer votre code source au monde? Bonne chance avec ça!

À mon avis, il est complètement fou de divulguer les bijoux de la propriété intellectuelle de la couronne à une autre entité jusqu'à ce que cette autre entité ait signé un NDA avec vous. Vous envisagez d'utiliser un service tel que github qui ne signe pas de NDA avec leurs clients. Ils offrent plutôt une vague promesse sous la forme d'un très long CLUF (accord de licence d'utilisateur final).

Github se rend compte que cela peut être un problème important et, par conséquent, il propose Github Enterprise comme mécanisme d'hébergement de code source (et d'autres éléments privés) sur son propre serveur.