Как автоматизировать настройку среды разработки?

Есть несколько вариантов, иногда полезно их сочетание:

• автоматическая установка
• образ диска
• виртуализация
• контроль исходного кода

Подробная информация о различных вариантах:

1. Автоматическая установка Инструменты для автоматизации установки и настройки различных служб, инструментов и файлов конфигурации рабочей станции:

   • Puppet has a learning curve but is powerful. You define classes of machines (development box, web server, etc.) and it then does what is necessary to install, configure, and keep the box in the proper state. You asked for one-click, but Puppet by default is zero-click, as it checks your machine periodically to make sure it is still configured as desired. It will detect when a file or mode has been changed, and fix the problem. I currently use this to maintain a handful of RedHat Linux boxes, though it's capable of handling thousands. (Does not support Windows as of 2009-05-08).
   • Cfengine — еще один. Я видел, как это успешно использовалось в магазине с 70 инженерами, использующими RedHat Linux. Его ограничения были одной из причин создания Puppet.
   • SmartFrog — еще один инструмент для настройки хостов. Он поддерживает Windows.
   • Скрипты оболочки. RightScale содержит примеры настройки Amazon EC2. изображение с помощью сценариев оболочки.
   • Установить пакеты. В системе Unix это можно сделать полностью с помощью пакетов, а в Windows можно использовать msi. Например, RubyWorks предоставляет вам полный стек Ruby on Rails, и все это путем установки одного пакета, который, в свою очередь, устанавливает другие пакеты через зависимости.

2. Образы дисков Конечно, существуют также инструменты создания образов дисков для хранения образ сконфигурированного хоста, чтобы его можно было восстановить на другом хосте. Как и в случае с виртуализацией, это особенно удобно для тестовых блоков, поскольку их легко восстановить с чистого листа. Постоянное обновление вещей по-прежнему является проблемой — стоит ли создавать новые образы только для того, чтобы распространять изменения в файле конфигурации?

3. Виртуализация — еще один вариант, например создание копий Xen, VirtualPC или образ VMWare для создания новых хостов. Это особенно полезно с тестовыми блоками, поскольку независимо от того, какой беспорядок создает тест, вы можете легко восстановить его до чистого известного состояния. Как и в случае с инструментами создания образов дисков, для поддержания хостов в актуальном состоянии требуется больше ручных действий и бдительности, чем при использовании автоматизированного инструмента установки/настройки.

4. Контроль исходного кода После того, как вы установили/настроили необходимые инструменты, выполнение сборок должно заключаться в проверке того, что необходимо, в репозитории исходного кода и его сборке.

В настоящее время я использую комбинацию вышеперечисленного для автоматизации процесса следующим образом:

• Начните с базовой установки ОС на гостевой системе VMWare.
• Запустите сценарий оболочки, чтобы установить Puppet и получить его конфигурации из системы управления исходным кодом.
• Puppet для установки инструментов/компонентов/конфигураций
• Извлекайте файлы из системы управления исходным кодом для создания и развертывания нашего веб-приложения.

Я наткнулся на этот вопрос и был очень удивлен, что никто еще не упомянул Vagrant.

Как упомянули Пит ТерМаат и другие, виртуализация — это отличный способ управления средами разработки и их автоматизации. Vagrant избавляет от необходимости настраивать эти виртуальные ящики.

В течение нескольких минут вы можете получить полностью новую копию вашего любимого дистрибутива Linux, работающую и подготовленную точно так же, как ваш рабочий сервер.

Больше не нужно бороться с OSX или Windows, чтобы установить PHP, MySQL и т. д. Все программное обеспечение живет и работает внутри виртуальной машины. Вы даже можете использовать SSH с помощью vagrant ssh. Если вы допустили ошибку или что-то сломали, просто vagrant destroy это и vagrant up, чтобы начать заново.

Vagrant автоматически создает синхронизированную папку в вашей локальной файловой системе. не нужно разрабатывать в виртуальной машине (т.е. с использованием Vim). Используйте любой редактор по вашему выбору.

Теперь я создаю новый «Бродячий ящик» почти для каждого проекта, который я делаю. Все мои настройки сохраняются в репозитории проекта, поэтому легко привлечь другого члена команды. Им просто нужно вытащить репозиторий и запустить vagrant up, и они буквально готовы к работе.

Это также значительно упрощает работу с проектами, которые имеют различные требования к программному обеспечению. Возможно, у вас есть проекты, основанные на PHP 5.3, но некоторые более новые проекты работают на PHP 5.4. Просто установите нужную версию для этого проекта.

Посмотрите!

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

Это означает, что вы также должны зарегистрировать вспомогательную инфраструктуру, такую ​​как файлы Makefile, файлы сборки ant и т. д., и настройки для инструментов, таких как файлы проекта IDE.

Это должно решить проблему с настройкой для отдельных проектов.

Для базовой настройки машины вы можете использовать стандартный образ. Другой вариант — использовать инструменты вашей платформы для автоматизации установки. В Linux вы можете создать метапакет, который зависит от всех необходимых вам пакетов. В Windows подобное должно быть возможно с использованием MSI или чего-то подобного.

Изменить:

В идеале вместо проверки вспомогательной инфраструктуры вы проверяете информацию, которая позволяет сборке генерировать вспомогательную инфраструктуру. Это подход, принятый, например. система сборки GNU (автоинструменты и т. д.) или Maven. Это еще более элегантно, потому что вы можете (теоретически) создавать инфраструктуру для любой (поддерживаемой) среды сборки, поэтому вы не обязаны, например. одна конкретная IDE, а настройки во вспомогательной инфраструктуре (пути и т. д.) не должны дублировать основные настройки проекта.

Однако это также более сложный подход, поэтому, если вы не можете заставить его работать, я считаю, что прямая проверка таких вещей, как файлы IDE, приемлема.

Мне нравится использовать Virtual PC или VMware для виртуализации среды разработки. Это обеспечивает стандартную «среду разработки», которую разработчики могут использовать совместно. Вам не нужно беспокоиться о программном обеспечении, которое пользователь может добавить в свою систему и которое может конфликтовать с вашей средой разработки. Это также дает мне возможность работать над двумя проектами, когда среды разработки не могут находиться в одной системе (используя две разные версии базовой технологии).

Используйте puppet для настройки среды разработки и рабочей среды. Использование первоклассной системы автоматизации — единственный способ масштабировать ваши операции.

Всегда есть возможность использовать виртуальные машины (см., например, VMWare Player). Создайте одну среду и скопируйте ее для каждого нового сотрудника с минимальной необходимой настройкой.

Раньше у нас было все (и я имею в виду ВСЕ) в SCM (чистый регистр, затем SVN). Когда новый разработчик может войти, он устанавливает ClearCase|SVN и загружает репозиторий. Это также касается случая, когда вам нужно обновить конкретную библиотеку/инструмент, поскольку вы можете просто попросить команды разработчиков обновить свою среду.

Для этого мы использовали два репозитория, поэтому код и инструменты/конфигурация находились в разных местах.

Я настоятельно рекомендую Blueprint от DevStructure. Это ПО с открытым исходным кодом, и ваш вариант использования на самом деле является точной причиной, по которой мы изначально написали программное обеспечение. Наши цели несколько изменились, но это по-прежнему идеальный инструмент для того, что вы описываете. Короче говоря, вы можете создавать повторно используемые конфигурации сервера — очень простое управление конфигурацией. Надеюсь, это поможет!

https://github.com/devstructure/blueprint (Blueprint @ Github)

Я сам думал об этом. Есть некоторые другие технологии, которые вы могли бы добавить в смесь. Вот что я сейчас настраиваю:

• Предустановленные установочные образы на основе PXE (Debian Squeeze). Вы можете запустить пустую машину (или новое виртуальное устройство) и выбрать образ в меню загрузки PXE. Это имеет большое преимущество, заключающееся в возможности установки вашей среды на физические машины (в дополнение к виртуальным устройствам).
• Кто-то уже упоминал Puppet. Я использую CFEngine, но это аналогичная сделка. По сути, ваша конфигурация задокументирована и централизована в файлах политик, которые постоянно применяются агентом на клиенте.
• если вам не нужна жесткая среда (т. е. разработчики могут выбирать комбинацию наборов инструментов), вы можете свернуть свои собственные пакеты deb, чтобы новые разработчики могли, например, вводить sudo apt-get install acmecorp-eclipse-env или sudo apt-get install acmecorp-intellij-env.
• Немного не по теме, но если вы используете среду на основе Debian (например, Ubuntu), рассмотрите возможность установки apt-cacher (пакетный прокси). Помимо экономии пропускной способности, это значительно ускорит установку (поскольку пакеты кэшируются в вашей локальной сети).

Если вы используете OSX и работаете с Rails. Я бы предложил либо:

• https://github.com/platform45/let-there-be-light
• https://github.com/thoughtbot/laptop

Если вы используете машины в стандартной конфигурации, вы можете создать образ диска со свежей идеально сконфигурированной установкой — это очень популярный подход во многих корпорациях (и не только среди разработчиков). Если вам нужны отдельно настроенные ОС, вы можете выполнить tar-bz2 все добавленные и измененные файлы после того, как сконфигурированная ОС будет преобразована в желаемую настройку, и просто распаковать ее как root, чтобы создать желаемую среду с нуля.

если вы используете вариант Linux, у вас, вероятно, есть система управления пакетами: думает .rpm для fedora/redhat или .deb для ubuntu/debian. многие из вещей, которые вы описываете, уже имеют доступные пакеты: svn, eclipse и т. д. вы можете свернуть свои собственные пакеты для программного обеспечения, специфичного для компании, создать репозиторий (возможно, доступный только в локальной сети), а затем ваша установка может быть сведена к одному bash, который добавит репозиторий компании в /etc/apt/sources.list (debian/ubuntu), а затем вызовет команду вроде

/home/newhire$ apt-get update && apt-get install some complete package list

вы можете использовать buildbot, чтобы затем автоматизировать регулярные сборки часто меняющихся пакетов компании.

Попробуйте DevScript на странице http://nsnihalsahu.github.io/devscript . Это одна команда, например, devscript lamp или devscript laravel или devscript django. Примерно через несколько минут, в зависимости от скорости вашего интернет-соединения.