Разработчики в моей команде хотят использовать общую машину разработки вместо запуска программного обеспечения на своих компьютерах. Их объяснение, похоже, состоит в том, что мы ориентируемся только на Fedora / CentOS / Red Hat для выпуска, и они используют Mac. Я попытался объяснить им, что для того, что мы делаем, им всем потребуется root на сервере, и один из них может легко сделать что-то вроде sudo rm -rf / (даже если случайно), таким образом убирая все работы, которые не проверены в системе контроля версий. Я сказал им загрузить CentOS и использовать VirtualBox для запуска кода.
Думаю, вопрос в том, кто прав? С моей точки зрения, проблемы совместного использования сервера разработки перевешивают незначительные неудобства, связанные с запуском CentOS на их машинах.
Чтобы разъяснить мой комментарий выше, должно быть абсолютно нет необходимость того, чтобы вашим разработчикам требовался root-доступ в вашей среде разработки, совместно используемой или иной. Благодаря сочетанию хорошо продуманных разрешений на файлы, дополненных несколькими правилами sudo, они должны иметь возможность делать все, что им нужно.
Что касается общей среды разработки по сравнению с тем, что у каждого разработчика есть собственная среда: я здесь с вашими разработчиками. Когда каждый разработчик управляет своей собственной средой разработки, вы получаете бесчисленное множество совершенно разных конфигураций, версий программного обеспечения, структур прав доступа к файлам, версий демонов, версий ядра и т. Д. страшный сон для устранения ошибок.
Они понимают, что им нужна стабильная, хорошо управляемая среда разработки. Они абсолютно правы, дайте им это!
Почему не оба - разработать на своей рабочей станции И протестировать на общем сервере разработки?
Если есть опасения по поводу потери данных, вы всегда можете запустить виртуальную машину поверх сервера разработки, сделать снимки машины и попросить разработчиков обновить код на этой виртуальной машине. В худшем случае вы всегда можете вернуть виртуальную машину к предыдущей резервной копии.
В аналогичной ситуации мы выбрали путь локальной разработки, но у нас есть независимый стек нашего приложения, работающий только для разработчиков и операторов (мы называем это интеграцией) для развертывания и тестирования. Разработчики имеют root-доступ, поэтому при необходимости они могут проводить расследование и устранять неполадки, но они знают, что система временная, поэтому в любой момент ее можно сдуть (и я делаю это как метод тестирования моих сценариев развертывания).
Если бы я был на вашем месте, я бы посмотрел на создание виртуальной машины, которая могла бы использоваться в их системах разработки, которая отражает настройку промежуточного сервера. Это дает им то, что им нужно, и никто не делает глупостей. Кроме того, если промежуточный сервер когда-либо выйдет из строя по какой-либо причине, вы не заставите всех ваших разработчиков вертеть пальцами, пока вы пытаетесь восстановить его ... как бы редко это ни происходило (не так редко, как вы 'd' думаю)
В моей компании есть как общие серверы разработки, так и личные локальные серверы. Дело в том, что у вас не может быть лучшего из обоих миров, но у вас может быть оба мира :) Я на стороне против общих серверов разработчиков, но я собираюсь упомянуть оба ниже.
Запуск локального сервера это настоящий кошмар для тех, кто не особо разбирается в сисадминах. Вы сказали, что ваши разработчики в основном используют Mac, и это только усугубляет ситуацию. Использование виртуальной машины действительно решает проблему различных ОС, но по-прежнему требует от них возможности управлять сервером, что не является их специальностью. Я нашел решение быть Бродяга. Это позволяет мне создавать код подготовки для виртуальной машины Virtualbox, и мои разработчики могут быть освобождены от задач обслуживания. Хотя мне приходится тратить дни, чтобы начать, и, возможно, часы на каждый новый проект, это сэкономило много времени, которое в противном случае мне пришлось бы помогать людям с установкой и настройкой пакетов.
Еще несколько преимуществ Vagrant:
Использование общего сервера имеет свои недостатки:
git commit, потому что вы не хотите фиксировать чужие изменения.При этом есть случаи, когда вам действительно нужен общий сервер разработки. По моему опыту, это включает:
Самый простой способ настроить общий сервер разработки - создать пользователя приложения, возможно, с именем проекта в качестве имени пользователя. Этот пользователь должен владеть всеми файлами, связанными с проектом. Затем добавьте открытые ключи ваших разработчиков в /home/<application>/.ssh/authorized_keys и ваши разработчики могут просто войти в систему как этот пользователь, чтобы что-то делать. Было бы полезно иметь соглашение при фиксации кода с использованием общей учетной записи, например, чтобы включить свои инициалы в сообщение фиксации, чтобы вы могли знать, какие коммиты принадлежат каким разработчикам.
В зависимости от вашего приложения рассмотрите возможность непрерывного развертывания. Разработчики должны проверять все свои изменения в системе контроля версий (CVS, SVN, GIT или что-то еще). Настройте триггер после фиксации для развертывания зафиксированных изменений.
В некоторых средах вам понадобится какой-то непрерывный процесс сборки. (Может быть достаточно ежечасной сборки.) Это дает разработчикам возможность проверить, как их изменения работают с изменениями других разработчиков.
Если вам действительно нужно, чтобы ваши разработчики запускали локальный сервер, стандартизируйте установку и конфигурацию. Возможно, удастся предоставить настройку по сценарию или даже проверить всю конфигурацию в вашей системе контроля версий. Не ждите, что ваши разработчики будут управлять серверами самостоятельно.
Используйте openindiana. Зоны обеспечивают виртуализацию на уровне операционной системы. Дайте каждому разработчику зону, к которой у них есть root-доступ. путь эффективнее виртуальной машины.
Все еще не уверен, зачем вам нужен root-доступ, но я бы хотел, чтобы зоны дали вам решение.
ВЫ ВСЕ ПРОПУСТИЛИ ТОЧКУ ????
ДЛЯ ВЕБ-РАЗРАБОТКИ: Dev-сервер должен быть ИДЕАЛЬНЫМ ОТРАЖЕНИЕМ реального сервера, на котором приложение будет находиться в LIVE PRODUCTION. ЗАЧЕМ? Потому что с точки зрения оборудования вы хотите быть уверены, что ваш живой сервер будет вести себя ТОЧНО как сервер Dev, на котором вы только что протестировали все свои вещи. Если оборудование отличается, результаты могут (читать: БУДЕТ) отличаться.
Если вы используете SVN или даже SourceSafe (система блокировки) Dreamweaver, вы достаточно защищены от ошибок, если ваши веб-разработчики знают, что делают. Потрясающий прогресс и сотрудничество, которые происходят, когда каждый может вносить свой вклад в проект напрямую, могут действительно помочь разработчикам узнать больше друг о друге, облегчая и упрощая последующие проекты.
ДЛЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ: Этика командной работы, о которой я только что говорил, все еще применима. Если все используют один сервер разработки, они по-прежнему получают выгоду от совместной работы и товарищества, но, конечно же, с программным обеспечением вы должны учитывать, на какой платформе (платформах) вы имеете в виду, чтобы оно работало. Итак, я бы сказал, что это рассмотрение каждого проекта отдельно. Вашим решением может быть «несколько общих серверов разработки для соответствия аппаратным характеристикам платформ, с которыми вы пытаетесь быть совместимыми».
При этом - если (читать: даже если) вы не Microsoft или Adobe, вы никогда не будете тестировать «достаточное количество» типов систем ...