Чи повинен ми розміщувати код в Інтернеті?

Ми шукаємо гарне рішення щодо управління джерелами та управління проектами на своєму робочому місці, і я запропонував створити організацію GitHub та приватні сховища. Я люблю GitHub з багатьох причин, але це не про GitHub (адже мої колеги збираються представити бали на користь конкуруючих платформ) - це про зберігання нашого приватного коду в Інтернеті .

Я намагаюся зрозуміти, хороша це ідея чи ні. Це, безумовно, здається вигідним, оскільки знімає потребу в серверних витратах (принаймні безпосередньо), а також полегшує пошук коду (все в мережі).

Однак наша команда не визначилась і підводить мене до свого запитання, що ми повинні розглянути, щоб прийняти це рішення?

Як професіонал,

Якщо офіс вашої компанії згоряє, код все ще залишається на сервері.

Якщо офіс вашої компанії не згоряє, але сервер, на якому розміщено ваш сховище git, ДУЖЕ, то у вас все ще є локальна копія.

Якщо ви розміщуєте своє сховище на своєму сервері в офісній будівлі вашої компанії (як, наприклад, із мережевим спільним накопичувачем ...?), То, якщо офіс компанії згоряє, ви втрачаєте обидва.

Звичайно, вам все одно потрібні резервні копії, як зазвичай ...

Не соромтеся замінювати "опіки" на "заражається вимогами".

В основному, доступність підвищена.

Як кон,

Вам доведеться поділитися своїми файлами з третьою стороною, яка розмістить ваш код. Якщо у вас справді великі секрети компанії, це може бути дозволено. Наприклад, якщо у вас є база даних, що містить особисту інформацію європейських громадян, можливо, вам не дозволять розміщувати свій код третій стороні зі США, оскільки вони підпадають під дію законодавства США, і тому на них не можна покластися підтримувати закони про конфіденційність ЄС. Навіть якщо це не є юридичним питанням, ви повинні пам’ятати, що третя сторона може бути підкуплена за видачу ваших приватних файлів. Це може бути дуже поганим для третьої сторони (величезна репутація покарання), але це може статися.

В основному конфіденційність знижена.

Якщо ви не хочете дотримуватися конфіденційності торгівлі щодо наявності, то розміщення вашого приватного коду в Інтернеті з третьою стороною - хороша ідея. Інакше не варто. Ви можете пояснити компроміси, щоб дозволити вашому начальникові приймати розумне рішення - але ви можете почути "ні". Ось що може статися, якщо ви хтось дасте рішення. Якщо ваш начальник каже ні, то це все. Я не думаю, що насильно переконувати вашого боса дуже гарна ідея.

Очевидно, це питання довіри до провайдера і наскільки ви цінуєте свій вихідний код.

Однак я вважаю своїм зрозумілим, що, принаймні в минулому, люди цінували свій вихідний код.

• Для продуктів «автоматизації бізнес-процесів»; де внутрішня команда створює веб-сайти та інше програмне забезпечення спеціально для потреб бізнесу. Цінність цього програмного забезпечення для інших людей, як правило, дуже низька.

• Для комерційного програмного забезпечення; це двійковий код, який ви продаєте, і його можна скопіювати і зламати без доступу до вихідного коду.

По-друге: Ви також повинні врахувати, чи зберігання вашого коду з третьою стороною насправді збільшує експозицію вище її поточного рівня. У багатьох випадках цього не буде

• Наприклад; якщо ваш продукт - це веб-сайт, який не містить коду, ваш код уже відкритий.
• Якщо ваш компільований код поширюється, його можна декомпілювати.
• Якщо ваш код - це веб-сайт або послуга, і ви розміщуєте його у третьої сторони. Тоді третя сторона може декомпілювати ваш код.
• Якщо ви зберігаєте резервні копії з третьою стороною, вони мають доступ до вашого коду.

Коротше кажучи, більшість сучасних підприємств довіряють різноманітним стороннім особам щоденний бізнес; навіть життєво важливі та унікальні для них речі.

Частиною цього процесу прийняття рішення може бути невелике тестування, випробування та помилки. Візьміть невеликий проект і попросіть декількох членів випробувати деякі з різних сайтів. Це повинно охоплювати зручність використання командою, але є й інші міркування.

1. Поточна інфраструктура - Деякі компанії вже мають сервери, підключення до Інтернету, VPN та персонал, який має навички розміщення серверів, тому деякі витрати та проблеми можуть бути покриті набагато простіше. Можливо, стартап буде більш схильний використовувати щось на зразок Github, оскільки їм не доведеться вкладати такі види інвестицій і може швидше встати та працювати.
2. Бюджет - багато аспектів №1 потраплять сюди, але можуть бути інші рішення із здоровенною ціною. Деякі компанії можуть виправдати витрати. Очевидно при низькому бюджеті багато варіантів усуваються.
3. Розподіл команди - Коли всі працюють в одному офісі протягом однієї години, можливо, вам не знадобиться github. Якщо ваш файловий сервер не надто обтяжений, просто покладіть на нього Git.
4. Безпека - Ви, ймовірно, можете знайти безліч захищених сайтів, але уявлення про безпеку для деяких клієнтів важливіше. Мати власну мережу залізобетонних плит може бути правильною справою, щоб завоювати їхню впевненість. Значки безпеки, сканери сітківки та озброєні охоронці просто кричать про безпеку деяких клієнтів.
5. Навчання - тут є більше, ніж просто використовувати додаток, є правила та процедури, які ваша компанія / команда хоче запровадити. Маючи уявлення про те, як ви хочете робити речі, можна керувати, якими інструментами користуватися. Залучення додаткових членів команди стає трохи легше, якщо їм подобається, як ви робите справи.

Почніть працювати над усім процесом кодування та доставки. Чим більше людей, які беруть участь у цьому процесі, тим краще. Ви не хочете приймати платформу управління джерелами, засновану на певних критеріях, лише щоб хтось із керівників міг все змінити. "Ця розповсюджена спритна річ не працює, тому нам потрібно, щоб усі почали працювати з офісу о 8-7, починаючи з понеділка, добре".

Я не обов'язково кажу, що вам не слід розміщувати сховище вашої компанії у хмарі, але я особисто відчував деякі недоліки та біль при хмарному хостингу.

Наскільки швидким та надійним є ваш Інтернет-зв’язок?

Для мене це найбільше значення. Наприклад, моя компанія знаходиться в досить сільській місцевості. У той час як наша внутрішньо -Net швидкість прокладає швидко, наші інтер -Net швидкість повільно , в кращому випадку , формений Flakey в гіршому випадку.

Залежно від того, який ДМС ви використовуєте, частина болю може бути пом’якшена. Розподілені системи управління версіями, як-от Git, не такі вже й погані, оскільки ви все ще можете працювати на місцях. Ви навіть можете запустити нове репо на мережевому диску, якщо вам дійсно потрібно поділитися деяким кодом з колегою. Для порівняння, ви не можете реально зробити жодну з цих речей з Team Foundation (незважаючи на всю локальну робочу область).

Але це лише код. У вашому сховищі, розміщеному у хмарі, є набагато більше, ніж просто код. Що з твоїми робочими предметами (функціями / списком помилок)? А як щодо вашої документації (вікі)? А як щодо вашої безперервної інтеграції? Усі ці речі, ймовірно, також будуть розміщені в хмарі поряд із вашим кодом. Якщо ваш Інтернет-зв’язок знизиться, як ви будете працювати без цих речей?

Gitlab пропонує безкоштовну версію для приміщення, яка, ймовірно, надасть більше, ніж потрібно вашій команді. Я настійно рекомендую встановити приміщення. Це значно знизить ризики.

Що ми повинні розглянути, щоб прийняти це рішення?

Вам слід розглянути недоліки. Я (разом з іншими) успішно закликав свого теперішнього роботодавця припинити розміщення коронних коштовностей компанії з інтелектуальної власності на приватному репортажі Github. Не сприймайте мене неправильно; github є фантастичним для програмного забезпечення з відкритим кодом.

Що стосується програмного забезпечення із закритим вихідним кодом, чи мали ви github.com (або якусь альтернативу) підписати угоду про нерозголошення (NDA), щоб не випускати свій вихідний код у світ? Успіхів у цьому!

На мою думку, відверто розкривати коштовності з інтелектуальної власності іншим юридичним особам до тих пір, поки ця інша організація не підпише з вами NDA. Ви плануєте використовувати таку послугу, як github, яка не підписує NDA з клієнтами. Натомість вони пропонують розпливчасту обіцянку у вигляді дуже тривалого EULA (ліцензійної угоди з кінцевим користувачем).

Самі Github розуміють, що це може бути суттєвою проблемою, і в результаті вони пропонують Github Enterprise як механізм розміщення вихідного коду (та інших приватних матеріалів) на власному сервері.