Вы разместили бы сервер управления исходным кодом как это?
- Я рекомендую следующую инфраструктуру:
- Главный сервер разработки, содержа управление исходным кодом, отслеживание ошибок, выполняет сборку VM и т.д. и т.д.
- Раскормленные рабочие станции разработчика/QA (или ноутбуки, при желании), чтобы действовать как рабочие столы и запустить тест разработчика VMs
- Протестируйте VMs на машине каждого разработчика, то зеркальное производство ОС/конфигурация, с которой они могут играть (для проверки идей об изменениях конфигурации, которые могли бы быть необходимы) и может сдуть и восстановить к известному состоянию (из основных изображений) при необходимости;
- Test/QA VMs на рабочих станциях отдела QA, так, чтобы отдельные тестеры могли справиться со своим собственным процессом тестирования/QA, не ступая ни на чьи больше пальцы ног;
- VM сборки/CI, где "известные хорошие" сборки могут быть произведены для внутреннего тестирования;
- Среда подготовки, которая зеркально отражает производство в каждом возможном уважении, которое используется, чтобы проверить полные сборки при подготовке к производственному выпуску и также проверить изменения в системной установке;
- Производство, которое заблокировано вниз от доступа разработчика, и которое является, где вся Реальная Работа происходит (очевидно),
- Существует также груда услуг по поддержке системного администратора, как золотой сервер, которые не непосредственно применимы к разработчику.
- На главном сервере разработки
- На рабочих станциях разработчика, любой непосредственно (в любой среде они чувствуют себя самыми продуктивными), или в их персональном тесте VMs.
Все это походит на излишество, если все, что Вы делаете, производит "относительно маленькие веб-сайты, каждого с определенным уникальным кодом". Это кажется, что Вы - человек-оркестр, в этом случае прикрепляете все это на Ваш ноутбук (с хорошей почти строкой и удаленными резервными копиями) в VMs как соответствующее. Что еще более важно, Вы захотите думать о том, как Вы структурируете свой код в допускающие повторное использование модули, и как Вы используете переходящие возможности своей системы управления версиями позволить общему коду быть распространенным, и уникальный код, чтобы остаться уникальными и не вмешаться друг в друга. Но это - вопрос, который лучше всего задают на Переполнении стека, не здесь.
Если бы Вы спрашиваете о 'большинстве компаний', я, вероятно, ответил бы на интранет VPN. И к тому же им, вероятно, основывались на некотором дублировании вершина (Набег, Некоторый робот ленты).
Если Вы задаетесь вопросом, что необходимо сделать, настройте сервер резервного копирования, просто получите некоторый NAS. Если Вы боитесь воровства, затем помещает тот сервер в некоторый другой шкаф. Если Вы боитесь огня, затем не курят около Вашего офиса... Необходимо пойти на некоторый компромисс при работе с маленьким бюджетом в небольшой компании (если это - случай).
-
1, но делает 'большинство компаний', выполняет их интранет (и исходный сервер) поле/поля в стенах их офиса, или в некотором центре обработки данных с их общедоступным материалом? – 9 November 2010 в 04:39
-
2я знаю, что иногда эти компании будут иметь внешние приложения направления на той же реальной машине как их внутренние серверы направления. Выгода, они виртуализируются и даны совершенно другие сетевые сегменты/правила маршрутизации. Я уверен, что Вы могли извлечь выгоду из виртуализации, если Вы уже не имеете и реализуете что-то подобное. – Marm0t 9 November 2010 в 04:41
-
3также, Вы могли разъяснить, как NAS используется в Вашем сценарии? большой – 9 November 2010 в 04:50
-
4Вы могли купить маленькую стойку (или башня) устройств хранения и затем иметь настроенный, чтобы быть сетевым устройством хранения данных. При текущем использовании гипервизора Вы могли бы автоматизировать резервные копии своего vms к тому сетевому пространству. – Marm0t 9 November 2010 в 05:04
Я выполнил бы сервер SVN локально и использовал бы удаленное резервное копирование (лента, rsync, онлайн, облачный, и т.д.). Если бы затронуто конфиденциальностью данных по удаленному резервному сервису я зашифровал бы данные и сохранил бы копию ключей шифрования в третьем местоположении (например, домой) или в fireproff безопасном от данных в офисе.
Не может быть полезно знать то, что делает большинство компаний, потому что они, вероятно, делают это в несметном числе путей, и наиболее распространенный способ не может удовлетворить Вашей определенной ситуации.
Обычно у Вас есть 3 безопасных опции. Я снабжу это предисловием с правовой оговоркой, что я работаю на ProjectLocker, таким образом, я обычно смещаюсь к размещенному решению для большинства компаний.
Разместите его сами, внутренне
Преимущества:
- Код только доступен в корпоративной сети, ограничивая источники риска
- Можно осуществить контрейлерные перевозки на существующей инфраструктуре безопасности компании вместо того, чтобы выяснить безопасность
Недостатки:
- Необходимо будет управлять программным обеспечением сервера так Вы, или кто-то в Вашей команде должен будет стать администратором Subversion, делание пользователя добавляет, возвращая сервер, и т.п..
- Если люди, которые должны получить доступ в репозиторий, будут на клиентских сайтах, где доступ VPN запрещается, они не смогут добраться до кода, где им нужен он. В моей прежней жизни как консультант программного обеспечения я часто видел это.
Используйте поставщика услуг хостинга
Преимущества:
- Большинство поставщиков услуг хостинга имеет интерфейсы для управления пользователями, созданием проекта, и управлением доступом, а также другими дополнительными свойствами, которые делают управление проектами легче. Это означает, что Вы не должны изучать входы и выходы администрирования Подверсии, и можно передать обязанности управления руководителям группы или другому доверяемому персоналу.
- Поставщики услуг хостинга обеспечивают безопасный доступ отовсюду и работу через большинство брандмауэров.
- Поставщикам услуг хостинга нечего делать кроме, удостоверяются, что серверы не ложатся спать, выполнение, и защищенный, таким образом, это легче и более дешево для них сделать 24x7 доступ и поддержка.
Недостатки:
- Это верно, что общедоступные серверы выставляются для больше риска по определению. Я утверждал бы, что риск больше для разрушения, чем воровство; если бы Вы не имеете дело с деньгами или правительственными секретами, более вероятно, что кто-то попытался бы принять сервер, чтобы поставить злонамеренную почту или кодировать и топать на Вашем коде как сопутствующий ущерб, чем который они украдут Ваш код и попытаются конкурировать с Вами на рынке или взломать Вашу систему. Тем не менее разрушенный проект является разрушенным проектом, и это - обоснованное опасение.
Настройте сервер в хостинговой компании
Преимущества:
- Вы имеете полный контроль над системой, контролем и безопасностью
- У Вашей команды есть доступ к коду отовсюду
Недостатки:
- Вы ответственны за администрирование и безопасность без преимущества инфраструктуры безопасности Вашей компании.
На основе этого я рекомендовал бы или размещающий внутренне или идущий с поставщиком услуг хостинга (Вы видите список их путем поиска с помощью Google для "хостинга подверсии"). Кажется, что хостинг себя с внешним поставщиком был бы худшим из обоих миров - необходимо будет иметь дело с безопасностью и администрированием без преимуществ инфраструктуры компании. Поставщики услуг хостинга делают ставку на свой бизнес при данных клиентов проверки, безопасны, и некоторые выполнят NDAs для обеспечения дополнительного обеспечения, таким образом, будет разумно доверять им достаточно, чтобы позволить им разместить код.