не уверен, подходит ли это для этого сайта, но начнем!
Ищу квалифицированного / опытного системного администратора Linux, с которым я могу поговорить о настройке среды разработки для удаленных людей, которые будут использоваться для проекта. (или если кто-то может указать мне на хороший сайт / статьи)
У меня есть 10-15 серверов, которые я хочу настроить в качестве среды разработки для создания пары приложений / проектов. Я предполагаю, что у меня будет test / backup / user directory / production / app servers / etc ...
Я хочу поговорить (по телефону / электронной почте) с кем-нибудь о том, как лучше всего собрать эту вещь ... хочу также убедиться, что система максимально защищена, поскольку разработчики проекта будут удаленно входить в систему. это для проекта, который может превратиться в проект с открытым исходным кодом, но я не хочу использовать sourceforge и просто вывешиваю проект для всех, пока он не пройдет несколько итераций ...
заранее спасибо за любые указатели / мысли / и т.д ...
Том...
Судя по вашей учетной записи StackOverflow, вы магазин Python.
Я рекомендую использовать BZR как ваш VCS, но это не имеет значения. Используйте то, что нравится вам и вашим разработчикам.
У вас должен быть (как минимум) один централизованный сервер разработки.
Он должен содержать главную копию вашего репозитория, а также домашние каталоги ваших разработчиков.
Взять регулярные резервные копии этого сервера.
Использовать rsnapshot чтобы делать моментальные снимки данных. Возможно, ежечасные снимки состояния или еженедельное резервное копирование вне офиса (Amazon S3 - отличное соотношение цены и качества!). Выполняйте еженедельное резервное копирование на автономный носитель (лента, DVD, внешний жесткий диск) и меняйте их ежемесячно.
Не забудьте протестировать восстановление!
Если у вас есть 2 сервера разработки, в идеале вы должны собрать их одинаково с помощью чего-то вроде ubuntu предварительный посевили RHEL / Centos Kickstart. Затем создайте серверные среды с помощью кукольный. Это сэкономит ваше время в долгосрочной перспективе, особенно при горизонтальном масштабировании.
Вы можете настроить репликацию на уровне файловой системы с помощью rsync между несколькими серверами разработки, но я лично рекомендую использовать общую систему хранения на уровне блоков, например GlusterFS.
Возьмите в привычку рано писать модульные тесты. Даже если это только для основных модулей ваших проектов. Интегрируйте их с бегуном модульного теста, скажем PyUnit. Получите анализатор покрытия кода, который поможет вам разработать эффективные тесты. Интегрируйте свою тестовую среду с системой управления версиями с помощью чего-то вроде Hudson или Buildbot. Теперь вы можете получить уведомление о том, какой разработчик зафиксировал код, нарушивший сборку.
У вас должен быть отдельный тестовый сервер, который отражает вашу живую среду. В идеале у вас есть два таких сервера: один в офисе для локального тестирования, а другой в том же центре обработки данных, где находятся ваши общедоступные серверы.
Причина наличия 2 заключается в том, что вы можете выполнять быстрое развертывание и тестирование на локальном, но тестировать среду, которая идентична действующим серверам, например различия в сети, межсетевые экраны, маршрутизация и т. Д.
После настройки и работы нескольких серверов вам следует подумать о какой-то централизованной системе резервного копирования. Сделайте резервную копию всех важных частей ваших серверов в центральном месте, а затем реплицируйте эти данные на отдельный сервер. Например, один в офисе, один в дата-центре.
А также еженедельное внешнее / автономное резервное копирование и тесты аварийного восстановления.
Опять же, многое из этого является «идеальным решением» и финансово невыгодно для небольших стартапов. Инвестиции в передовой опыт на раннем этапе окупаются в будущем. Особенно вещи, которые ограничивают время простоя, когда вы пытаетесь быстро масштабироваться.
Хороший контроль версий и продуктивный рабочий процесс разработки тоже имеют большое значение.
Вы действительно нужно столько серверов для «пары приложений / проектов»? Мне это кажется излишним.
Чтобы дать небольшую перспективу, я работаю в компании со 130 сотрудниками, и я обслуживаю 11 серверов.
Одно можно сказать наверняка: вам будет разумно настроить свой любимый сервер контроля версий на самом раннем этапе процесса.