Настройка сервера непрерывной интеграции: от разработки до производства - PullRequest
Новая
       24

Настройка сервера непрерывной интеграции: от разработки до производства

1 голос
/ 15 мая 2009

Мы находимся в процессе переконфигурирования нашей серверной среды, от разработки до производства. Все серверы будут серверами Windows 2008, работающими как виртуальные машины. Мы будем использовать TeamCity для непрерывной интеграции и SubVersion в качестве нашей системы контроля версий.

После прочтения некоторых рекомендаций я планирую продолжить (не включая избыточность, аварийное восстановление и т. Д.):

  • Производство: (1) Веб-сервер + (1) Сервер БД
  • Стадия: (1) Веб-сервер + (1) Сервер БД
  • Сборка: (1) SVN + TeamCity Web и DB + (1) TeamCity Agent
  • Разработка: (1) Web / DB Server

Итого 2 производства + 2 этапа + 2-3 сборки + 1 разработчик = 7-8 серверов

Мои вопросы были:

  1. Должен ли SVN находиться на выделенном сервере или он может жить на сервере Dev?

    Ответ: До сих пор Concensus, похоже, считает, что SVN не должен находиться на сервере Dev. Он должен быть либо автономным, либо может быть связан на том же сервере, что и TeamCity.

  2. Должен ли TeamCity находиться на выделенном сервере или он может жить на сервере SVN?

    Ответ: До сих пор было замечено, что TeamCity может находиться на том же сервере, что и SVN, особенно если агенты TeamCity и БД SQL находятся на отдельных серверах.

  3. Любые другие рекомендации, лучшие практики?

    Ответ: TeamCity следует разделить на 3 экземпляра сервера: один для TeamCity Web, один для агентов TeamCity и один для базы данных SQL TeamCity.

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

Ответы [ 2 ]

2 голосов
/ 15 мая 2009

Чтобы ответить на ваши вопросы:

  • Я бы поставил SVN на другой сервер, нежели сервер dev. Часто на серверах разработчиков устанавливается всякая ерунда.
  • TeamCity может находиться на том же сервере, что и сервер SVN. (Назовите это своим сервером сборки)
  • В вашей производственной системе нет встроенной устойчивости.
    Я бы посоветовал иметь как минимум еще два сервера, еще один веб-сервер и сервер БД с горячим резервированием, который будет зеркалирован с вашего живого сервера БД. Они не должны находиться в том же центре обработки данных, что и остальные ваши серверы, и должны использовать альтернативные шлюзы для выхода в Интернет.
1 голос
/ 15 мая 2009

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

  • Веб-сервер TeamCity работает на Сам Tomcat, и использует хорошую сделку памяти (как и любое приложение Tomcat).
  • Агенты TeamCity Build, так как они скомпилируйте, используйте тонну памяти.
  • SQL Server - это проблема с памятью.

JetBrains упоминает, что агенты сборки не должны оптимально работать на том же сервере, что и веб-сервер. Я бы посоветовал также разделить базу данных (на физический блок, а не только на виртуальную машину), чтобы сама установка CI использовала 3 системы (веб-сервер TeamCity, база данных TeamCity, агент сборки TeamCity). Если ваши сборки занимают более нескольких минут, я бы добавил еще один сервер агента сборки, чтобы разработчики не стояли в очереди на коммиты, особенно если вы используете функцию удаленного запуска / личной сборки TeamCity из IDEA или Eclipse.

У меня не возникло бы проблем с размещением сервера SVN в той же системе, что и веб-сервер TeamCity.

Имейте в виду, что компиляция - это действие, которое обычно связано с процессором или доступом к диску. Агенты сборки выиграют от разделения на отдельные процессоры и / или диски. Однако нахождение на отдельных виртуальных машинах, которые совместно используют диски и процессоры, может быть более расточительным, чем полезным из-за накладных расходов нескольких виртуальных машин.

...