Як автоматизувати налаштування середовища розробки? [зачинено]

Кожного разу, коли новий розробник приєднується до команди або на комп’ютері, на якому розробник використовує зміни, розробнику потрібно виконати багато роботи з налаштування локального середовища розробки, щоб поточний проект працював. Як команда SCRUM ми намагаємося автоматизувати все, включаючи розгортання та тести, тому я запитую: чи є інструмент або практика для автоматизації налаштування середовища місцевого розвитку?

Наприклад, щоб налаштувати моє середовище, спочатку мені довелося встановити eclipse, потім SVN, Apache, Tomcat, MySQL, PHP. Після цього я заповнив БД, і мені довелося внести незначні зміни в різні файли конфігурації тощо ... Чи є спосіб зменшити цю працю до одного клацання?

Є кілька варіантів, і іноді їх поєднання корисно:

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

Детальна інформація про різні варіанти:

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

   • Лялька має криву навчання, але потужна. Ви визначаєте класи машин (вікно розробки, веб-сервер тощо), а потім виконує те, що потрібно для встановлення, налаштування та підтримання вікна у належному стані. Ви попросили один клік, але за замовчуванням Ляльковий - це нульовий клік, оскільки він періодично перевіряє вашу машину, щоб переконатися, що вона все ще налаштована за бажанням. Він виявить, коли файл або режим було змінено, і вирішить проблему. В даний час я використовую це для підтримки декількох ящиків RedHat Linux, хоча він здатний обробляти тисячі. (Не підтримує Windows станом на 08.05.2009).
   • Цфенгін - ще один. Я бачив, як це вдало використовується в магазині із 70 інженерами, що використовують RedHat Linux. Його обмеження були частиною причини для Ляльки.
   • SmartFrog - ще один інструмент для налаштування хостів. Він підтримує Windows.
   • Сценарії оболонки. RightScale має приклади налаштування образу Amazon EC2 за допомогою скриптів оболонки.
   • Встановіть пакети. На коробці Unix це можна зробити повністю за допомогою пакетів, а в Windows msi може бути опцією. Наприклад, RubyWorks надає вам повний стек Ruby on Rails, і все це шляхом встановлення одного пакета, який, у свою чергу, встановлює інші пакети через залежності.

2. Зображення диска Тоді, звичайно, існують також засоби обробки зображень диска для зберігання образу налаштованого хосту, щоб його можна було відновити на іншому хості. Як і у випадку з віртуалізацією, це особливо приємно для тестових скриньок, оскільки легко відновити речі до чистого аркуша. Постійне оновлення речей залишається проблемою - чи варто робити нові зображення лише для поширення зміни конфігураційного файлу?

3. Віртуалізація - це ще один варіант, наприклад, створення копій образу Xen, VirtualPC або VMWare для створення нових хостів. Це особливо корисно у тестових коробках, оскільки незалежно від того, який безлад створює тест, ви можете легко відновити його до чистого, відомого стану. Як і для інструментів візуалізації дисків, для оновлення хостів потрібно більше ручних кроків та пильності, ніж якщо використовується автоматизований інструмент встановлення / налаштування.

4. Контроль вихідного коду Після того, як ви встановили / налаштували необхідні інструменти, тоді збирання повинно бути питанням перевірки того, що потрібно зі сховища вихідного коду, та його побудови.

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

• Почніть із встановлення ОС Barebones на гостя VMWare
• Запустіть скрипт оболонки, щоб встановити Puppet і отримати його конфігурації з елемента керування вихідним кодом
• Маріонетка для встановлення інструментів / компонентів / конфігурацій
• Перегляньте файли з контролю вихідного коду, щоб створити та розгорнути наш веб-додаток

Я випадково натрапив на це питання і був дуже здивований тим, що про Вагранта ще ніхто не згадував .

Як зазначали Піт ТерМат та інші, віртуалізація - це чудовий спосіб управління та автоматизації середовищ розробки. Vagrant в основному знімає біль від налаштування цих віртуальних скриньок.

Через кілька хвилин ви можете мати абсолютно нову копію вашого улюбленого Linux дистрибутив і працює, і надані точно так же , як ваш виробничий сервер буде.

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

Vagrant автоматично створює синхронізовану папку для вашої локальної файлової системи, тобто вам не потрібно розробляти у віртуальній машині (тобто за допомогою Vim). Використовуйте будь-який вибраний вами редактор.

Зараз я створюю нову «коробку бродяг» майже для кожного свого проекту. Усі мої налаштування зберігаються у сховищі проектів, тому легко залучити іншого члена команди. Їм просто потрібно витягнути репо і бігти vagrant up, і вони буквально готові до роботи.

Це також значно полегшує роботу з проектами, що мають різні вимоги до програмного забезпечення. Можливо, у вас є деякі проекти, які покладаються на PHP 5.3, але деякі новіші, на яких працює PHP 5.4. Просто встановіть потрібну версію для цього проекту.

Перевір!

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

Це означає, що вам слід також перевірити допоміжну інфраструктуру, таку як Makefiles, ant buildfiles тощо, а також налаштування інструментів, таких як файли проектів IDE.

Це повинно подбати про клопоти з налаштуванням для окремих проектів.

Для базового налаштування машини можна використовувати стандартне зображення. Інший варіант - використовувати інструменти вашої платформи для автоматизації встановлення. В Linux ви можете створити мета-пакет, який залежить від усіх необхідних вам пакетів. В ОС Windows подібне може бути можливим за допомогою MSI тощо.

Редагувати:

В ідеалі, замість перевірки допоміжної інфраструктури, ви перевіряєте інформацію, яка дозволяє збірці генерувати допоміжну інфраструктуру. Цей підхід застосовується, наприклад, системою побудови GNU (автоінструменти тощо), або Maven. Це ще більш елегантно, оскільки ви можете (теоретично) генерувати інфраструктуру для будь-якого (підтримуваного) середовища збірки, отже, ви не зобов'язані, наприклад, однією конкретною IDE, а параметри допоміжної інфраструктури (шляхи тощо) не повинні дублювати основні налаштування проекту.

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

Я люблю використовувати Virtual PC або VMware для віртуалізації середовища розробки. Це забезпечує стандартне "середовище розробника", яким можуть користуватися розробники. Вам не потрібно турбуватися про програмне забезпечення, яке користувач може додати до своєї системи, що може суперечити вашому середовищу розробки. Це також дає мені можливість працювати над двома проектами, де середовища розробки не можуть обидва бути в одній системі (використовуючи дві різні версії базової технології).

Використовуйте маріонетку для налаштування середовища розробки та виробництва. Використання першокласної системи автоматизації - це єдиний спосіб масштабувати ваші операції.

Завжди є можливість використання віртуальних машин (див., Наприклад, VMWare Player ). Створіть одне середовище та скопіюйте його для кожного нового працівника з мінімальною необхідною конфігурацією.

У попередньому місці у нас було все (і я маю на увазі ВСЕ) в SCM (чітка справа тоді SVN). Коли новий розробник може, вони встановили ClearCase | SVN і висмоктали сховище. Це також обробляє випадок, коли вам потрібно оновити певну бібліотеку / інструмент, оскільки ви можете просто запропонувати командам розробників оновити своє середовище.

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

Я настійно рекомендую Blueprint від DevStructure. Це з відкритим кодом, і ваш випадок використання насправді є точною причиною того, що ми спочатку написали програмне забезпечення. Наші цілі дещо змінилися, але це все ще є ідеальним інструментом для того, що ви описуєте. Коротше кажучи, ви можете створювати конфігурації сервера багаторазового використання - просто просте управління конфігурацією. Сподіваюся, це допоможе!

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

Я сам про це думав. Є деякі інші технології, які ви могли б використати. Ось що я зараз налаштовую:

• Попередньо встановлені образи інсталяції на основі PXE (Debian Squeeze). Ви можете запустити оголену металеву машину (або новий віртуальний прилад) і вибрати зображення в меню завантаження PXE. У цьому є головна перевага можливості встановлення середовища на фізичних машинах (крім віртуальних приладів).
• Хтось уже згадав Ляльку. Я використовую 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 усі додані та змінені файли, як тільки налаштована ОС перетвориться на потрібну вам установку, і просто зняти її з корінь, щоб зробити бажане середовище з нуля.

якщо ви використовуєте аромат 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. Приблизно за кілька хвилин, залежно від швидкості вашого Інтернету