Хотели бы вы разместить сервер управления исходным кодом?

Как правило, у вас есть 3 безопасных варианта. Я предваряю это заявлением об отказе от ответственности, которое я работаю для ProjectLocker, поэтому я обычно склоняюсь к хост-решению для большинства компаний.

Примите это сами, внутренне

Преимущества:

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

Недостатки:

• Вам нужно будет управлять серверным программным обеспечением, чтобы вы или кто-то из вашей команды должны были стать администратором Subversion, делать добавления пользователей, отскакивать от сервера и тому подобное.
• Если люди, которым нужен доступ к хранилищу, находятся на клиентских сайтах, где доступ VPN запрещен, они не смогут получить код там, где он нужен. В моей прошлой жизни в качестве консультанта по программному обеспечению я часто видел это.

Используйте хостинг-провайдера

Преимущества:

• У большинства хостинг-провайдеров есть интерфейсы для управления пользователями, создания проектов и контроля доступа, а также других наворотов, которые облегчают управление проектами. Это означает, что вам не нужно изучать все тонкости администрирования Subversion, и вы можете передать управленческие обязанности руководителям группы или другому доверенному персоналу.
• Хостинг-провайдеры обеспечивают безопасный доступ из любой точки мира и работают через большинство межсетевых экранов.
• Хостинг-провайдерам ничего не нужно делать, кроме как убедиться, что серверы работают, работают и защищены, поэтому им проще и дешевле осуществлять доступ и поддержку 24x7.

Недостатки:

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

Настройка сервера в хостинговой компании

Преимущества:

• Вы имеете полный контроль над системой, мониторинг и безопасность
• Ваша команда имеет доступ к коду из любого места

Недостатки:

• Вы несете ответственность за администрирование и безопасность без использования инфраструктуры безопасности вашей компании.

Исходя из этого, я бы порекомендовал либо хостинг внутри компании, либо переходить к хостинг-провайдеру (вы можете увидеть их список по Googling для "subversion хостинга"). Кажется, что хостинг с внешним провайдером был бы худшим из двух миров - вам пришлось бы иметь дело с безопасностью и администрированием без преимуществ инфраструктуры вашей компании. Хостинг-провайдеры делают ставку на то, чтобы обеспечить безопасность данных клиентов, а некоторые будут выполнять NDA, чтобы обеспечить дополнительную уверенность, поэтому разумно доверять им достаточно, чтобы позволить им разместить ваш код.

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

Если вы спрашиваете о "большинстве компаний", я, вероятно, отвечу на интранет VPN. И вдобавок к этому у них, вероятно, есть какая-то избыточность, встроенная сверху (Raid, Какой-то ленточный робот).

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

Я бы запускал сервер SVN локально и использовал резервное копирование вне сайта (лента, rsync, онлайн, облачно и т. Д.). Если бы я беспокоился о конфиденциальности данных в стороннем сервисе резервного копирования, я бы зашифровал данные и сохранил бы копию ключей шифрования в третьем месте (например, дома) или в защищенном от взлома хранилище данных в офисе.

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