Должны ли мы размещать код онлайн?

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

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

Однако наша команда не определилась и приводит меня к моему вопросу, что мы должны рассмотреть, чтобы принять это решение?

Как профессионал,

Если офис вашей компании сгорел, код все еще находится на сервере.

Если офис вашей компании не сгорел, но сервер, на котором находится ваш git-репозиторий, ДЕЙСТВИТЕЛЬНО, то у вас все еще есть локальная копия.

Если вы разместите свой репозиторий на своем сервере в офисном здании вашей компании (как если бы вы использовали сетевой диск с общим доступом ...?), То, если офис компании сгорит, вы потеряете оба.

Конечно, вам все еще нужны резервные копии как обычно ...

Не стесняйтесь заменить «сгорает» на «заражается вымогателями».

В основном, доступность вверх.

Как мошенник,

Вы должны будете поделиться своими файлами с третьей стороной, которая будет размещать ваш код. Если у вас есть действительно большие секреты компании, это может быть запрещено. Например, если у вас есть база данных, содержащая личную информацию от граждан Европы, вам может быть запрещено размещать свой код у третьих лиц из США - потому что они будут подчиняться законодательству США и, следовательно, не могут полагаться на соблюдать законы ЕС о конфиденциальности. Даже если это не юридическая проблема, вы должны знать, что третья сторона может быть подкуплена для передачи ваших личных файлов. Вероятно, это будет очень плохо для третьей стороны (огромный штраф репутации), но это может произойти.

По сути, конфиденциальность нарушена.

Если вы согласны с конфиденциальностью торговли для доступности, то размещение вашего личного кода в сети с третьей стороной является хорошей идеей. В противном случае нет. Вы могли бы объяснить компромиссы, чтобы ваш босс мог принять разумное решение, но вы можете услышать «нет». Вот что может случиться, если вы дадите кому-то решение. Если твой босс говорит нет, то это так. Я не думаю, что насильно убедить вашего босса - это очень хорошая идея.

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

Тем не менее, я думаю, ясно, что, по крайней мере, в прошлом, люди переоценили свой исходный код.

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

• Для продаваемого программного обеспечения; это бинарный файл, который вы продаете, и который можно скопировать и взломать без доступа к исходному коду.

Во-вторых: Вам также следует подумать о том, действительно ли хранение вашего кода третьим лицом увеличивает вашу подверженность риску выше его текущего уровня. Во многих случаях это не будет

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

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

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

1. Текущая инфраструктура. У некоторых компаний уже есть серверы, подключения к Интернету, VPN и персонал, обладающий навыками размещения серверов, поэтому некоторые затраты и проблемы могут быть решены намного проще. Стартап может быть более склонен использовать что-то вроде Github, потому что ему не нужно делать такие инвестиции, и он может быстрее начать работу.
2. Бюджет - многие аспекты # 1 будут подпадают под это, но могут быть и другие решения с дорогой ценой. Некоторые компании могут оправдать расходы. Очевидно, с низким бюджетом, многие варианты исключены.
3. Распределение команды - когда все работают в одном и том же офисе в одно и то же время, вам может не понадобиться github. Если ваш файловый сервер не слишком загружен, просто установите на него Git.
4. Безопасность. Вы можете найти множество защищенных сайтов, но для некоторых клиентов важнее восприятие безопасности. Иметь свою собственную железную сеть может быть правильным, чтобы завоевать их доверие. Знаки безопасности, сканеры сетчатки и вооруженные охранники просто кричат ​​о безопасности для некоторых клиентов.
5. Обучение - это больше, чем просто использование приложения, есть правила и процедуры, которые ваша компания / команда хочет внедрить. Представление о том, как вы хотите что-то делать, может определять, какие инструменты использовать. Привлечение дополнительных членов команды становится немного легче, если им нравится, как вы делаете вещи.

Начните работать через весь процесс кодирования и доставки. Чем больше людей вовлечено в этот процесс, тем лучше. Вы не хотите принимать платформу управления исходным кодом, основанную на определенных критериях, только чтобы кто-то в управлении изменил все. «Эта распределенная гибкая вещь не работает, поэтому нам нужно, чтобы все начали работать из офиса в 8-7, начиная с понедельника, хорошо».

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

Как быстро и надежно ваше интернет-соединение?

Для меня это самое большое соображение. Например, моя компания находится в красивой сельской местности. В то время как наша внутри- -Net скорость прокладывает быстро, наши интер -Net скорость медленно , в лучшем случае , форменный Flakey в худшем случае.

В зависимости от того, какую VCS вы используете, некоторая часть боли может быть смягчена. Распределенные системы контроля версий, такие как Git, не так уж и плохи, потому что вы все еще можете работать локально. Вы даже можете инициировать новое репо на сетевом диске, если вам действительно нужно поделиться кодом с коллегой. Для сравнения, вы не можете сделать ни одну из этих вещей с Team Foundation (несмотря на всю локальную рабочую область).

Но это всего лишь код. В вашем облачном хранилище гораздо больше, чем просто код. А как насчет ваших рабочих элементов (функции / список ошибок)? А как насчет вашей документации (вики)? А как насчет вашей непрерывной интеграции сборки? Все эти вещи, вероятно, также будут размещены в облаке вместе с вашим кодом. Если ваше интернет-соединение оборвется, как вы будете работать без этих вещей?

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

Что мы должны рассмотреть, чтобы принять это решение?

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

В случае с программным обеспечением с закрытым исходным кодом, вы должны были github.com (или какой-либо другой вариант) подписать соглашение о неразглашении (NDA), чтобы не публиковать ваш исходный код в мире? Удачи с этим!

На мой взгляд, совершенно безумно раскрывать свои драгоценности короны какой-либо другой организации, пока эта другая организация не подпишет с вами соглашение о неразглашении. Вы планируете использовать такой сервис, как github, который не подписывает соглашения о неразглашении со своими клиентами. Вместо этого они предлагают смутное обещание в виде очень длинного лицензионного соглашения (конечного пользователя).

Сами Github понимают, что это может быть серьезной проблемой, и в результате они предлагают Github Enterprise в качестве механизма для размещения исходного кода (и других личных вещей) на своем собственном сервере.