Якщо ви робите сольний проект - чи використовуєте ви інструменти CI для створення зі сховища? Я використовував Хадсона та Круїз-контроль в командному середовищі, де важливо будувати, як тільки хтось щось перевіряє.
Я думаю, що цінність контролю версій все ще очевидна, але чи потрібно будувати її після кожного вчинення, бачачи, як я просто будував би свою локальну машину, і ніхто більше не робить цього?
Відповіді:
Ну я планую використовувати інструмент безперервної інтеграції в проекті, і я унікальний розробник. Потреба приходить тому, що
Крім кросплатформної та командної роботи, я не бачу потреби. Головне - мати якесь програмне забезпечення для управління джерелами та мати декілька сховищ для зберігання резервних копій. Це допоможе вам налаштувати інструменти для створення навколо нього, коли це необхідно.
Щодо часу збирання, я використовую Mercurial і налаштовую сховище інтеграції, яке не є сховищем для командної роботи. Отже, натисніть на зміни в репо-команді, поки я не відчуваю, що настав час спробувати створити інтеграційну систему. Потім я переходжу від командної роботи репо до інтеграційного репо, і це призведе до нарощування. Тоді я також додаю сценарій, який витягуватиме репо для командної роботи в репортаж інтеграції один раз щодня.
Тут я припускаю, що майже весь день працюю над своїм проектом, але це не завжди так. Ви повинні встановити терміни збірки, які відносяться до того, як часто вам потрібні збірки. У ігровій компанії, в якій я працював раніше, ми використовували CruiseControle, і вона будувала повний збір щогодини. Ми також можемо змусити будувати, коли нам захочеться, якщо потрібно.
Для домашнього проекту один раз на день може бути вже "часто". Головною вимогою було б легко дозволити користувачеві примушувати запускати збірку.
Після недовгого роздуму я б припустив , що це може бути навіть більш важливим для розробника соло , ніж для команди.
На самому базовому рівні сервер CI демонструє, що ви можете будувати свою програму з нуля з довіреного джерела - у поєднанні з гідним набором тестів він повинен демонструвати, що ви можете створювати та працювати з нуля.
Оскільки одна з речей, яку я намагаюся зробити, - це забезпечити, щоб моя збірка включала розгорнутий пакет, ви також знаєте, що ви можете перейти щось до розгортання (чисте та з відомого стану / версії).
Насправді зараз, коли ви робите File | New Project, ви, ймовірно, повинні включати створення або додавання до свого сховища та налаштування сценарію збирання CI та налаштування розгортання (навіть якщо це лише для того, щоб зібрати купу матеріалів для розгортання xcopy)
Додаток (2016) - на сьогодні моя система ІС також буде невід’ємною частиною мого процесу розгортання, тому її значення зросла, і я абсолютно не буду виконувати жоден проект, що може бути виконаний без нього. Автоматичне розгортання кнопки забирає велику напругу під час процесу і певним чином формувати або формувати сервер збирання є невід’ємною частиною цього.
Коли я єдиний, хто вчиняє, я просто будую і тестую перед тим, як насправді здійснити. Зазвичай я використовую ціль makefile на зразок:
make sense
Це налаштовує, будує, виконує всі тести (знає valgrind), запускає линзи і т. Д. Як я знаю, я буду єдиним, хто штовхає, мені не дуже потрібна сила чимось на зразок Хадсона.
Крім того, у середовищі, де у вас є кілька гілок, що живлять основне сховище, якщо всі слідкують за завжди витягуванням перед тим, як здійснити чи натиснути, сервер CI може бути трохи перевищений. Добре написане правило, що автор того, що зламав останній збір, купує піцу в п’ятницю, як правило, все працює дуже гладко :)
Якщо він потрапить у ситуацію, коли проект чітко розділений на підсистеми, у яких є свої лідери, вам дійсно потрібно задуматися, використовуючи щось на зразок Хадсона. Хтось може протестувати локально, програти гонку з іншою підсистемою і в кінцевому підсумку натиснути щось токсичне.
Крім того, якщо ви підтримуєте вилку швидко рухається проекту (наприклад, власний набір патчів до ядра Linux), вам слід подумати про використання такого типу, як Хадсон, навіть якщо ви «соло» у цьому проекті. Особливо це стосується, якщо ви від'єднаєтесь / повторно базуєтесь безпосередньо від лінії.
make: don't know how to make sense. Stop. Арг!
Я б не сказав, що це лише приємний бонус, я б сказав, що це важливо для високоякісної інженерії програмного забезпечення для нас, сольних артистів. Більшість із нас дозволить їх стандартам якості трохи знизитися, якщо вони поспішають, якщо вони вважають, що це досить легко виправити пізніше. Якщо ви здійснюєте програмне забезпечення в такому стані, у вас, по суті, є нікчемна база даних, що зберігається у вашому контролі джерела.
Якщо ви дотримуєтесь належного (тобто ви не пропускаєте тести, і переконуєтесь, що вони складаються щоразу, коли ви здійснюєте), CI змушує вас дотримуватися більш високого стандарту якості, ніж ви б, якщо ви просто все-таки це зробите.
Важливо, якщо ви хочете скоротити час очікування, щоб побачити, чи все ще добре. Хоча ви можете змусити ваш IDE складати для вас речі, як тільки ви збережете, він не запускає автоматично тести одиниць, тому я маю, щоб мій сервер CI запустив одиничні тести та звіти про покриття тестових випадків та інший аналіз якості мого коду, як тільки Я його штовхаю.
Єдиний спусковий механізм, який мені потрібно зробити, - це натиснути мої поточні зміни на контроль версій, і я можу повернутися до кодування. І хоча я замислююсь над кодуванням, система CI зайнята тим, щоб робити довгі звиті звіти про якість, які я переглядаю час від часу, коли мій мозок затихне.
У мене на тому ж ноутбуці є окрема машина VMWare, яка виконує побудову коду, на який я натискаю. Для цього я просто отримую зображення VMWare під ключ Linux і встановлюю джинкіни за допомогою apt-get і роблю кілька незначних змін конфігурації.