Назад | Перейти на главную страницу

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

Вопрос:

Я ищу ссылки или личные учетные записи уроков и опыта по настройке наборов серверов \ систем для разработчиков. В частности меня интересует количество автоматизация и если оказалось, что работы больше, чем стоит, или пошли бог. Я понимаю, что в зависимости от характера разрабатываемых продуктов это может быть проще или сложнее. Я также новичок в этой области (<4 месяцев), поэтому мой взгляд очень ограничен :( Следующие моменты меня больше всего интересуют:


Мой ограниченный опыт

В моем случае команда развивается веб-приложения с использованием MySQL и PHP. Обновленная инфраструктура, над которой я работал, дает им возможность контроля версий с помощью Mercurial и системы управления проектами Redmine. У нас также есть серверы разработки, тестирования и производства для сайта, а также сервер базы данных. Я совмещаю контроль версий и управление проектами на одном сервере.

С точки зрения удобства использования вышеупомянутого размещения на их собственных серверах достаточно, но я работал над подходами, использующими перехватчики после фиксации для автоматической отправки новейших входящих коммитов на сервер разработки, обработки сценариев (например, минимизации файлов CSS и JS), и интеграция триггеров публикаций для тестирования и разработки в пользовательские интерфейсы Redmine с контролем разрешений. Я также добавил хуки в Redmine для создания и удаления настраиваемого репозитория (с настраиваемыми хуками).

Я также экспериментировал с настраиваемыми плагинами Dreamweaver, чтобы получать сообщения о фиксации от разработчиков и автоматически обрабатывать процесс фиксации (минимизируя время, затрачиваемое на переключение окон и щелчки в TortoiseHg).

Поскольку я все еще тестирую, я не уверен, что из этого получится. Мне было просто любопытно, что сделали другие, насколько они забегали.

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

Еще несколько конкретных ответов:

Контроль версий: мы используем svn, cvs и git (по устаревшим причинам, сейчас предпринимаются шаги по объединению этого только в git).
Автоматизация: много. Каждая из этих систем имеет множество скриптов перехвата. Из-за того, что требования постоянно меняются, у инженерных групп фактически есть «производитель инструментов», то есть конкретный инженер-программист, который ничего не делает, кроме как предоставляет и улучшает инструменты для всех остальных. ИТ-команда на самом деле вообще этим не занимается, мы фокусируемся на серверах как таковых (оборудование, ОС, обновления, производительность, сети и т. Д.)
Консоль против графического интерфейса: Все идет. И нам в ИТ не очень важно, что они используют, пока это работает, может быть установлено / обновлено с помощью управления пакетами (у нас также есть собственный репозиторий пакетов для наших внутренних инструментов) и не нарушает никаких законов и не нарушает любые авторские права.
Приоритет # 1 всегда бесперебойный сервис для всех пользователей.