Вступ і передісторія

Досить часто доводиться чути думку, що Сontinuous Integration (CI), Автотест як складова CI, утиліти процесингу коду створені виключно для великих корпоративних проектів, і ніяк не застосовні для чогось меншого. У статті не буду намагатися умовити вас використовувати щось з перерахованого, просто приведу деякий набір практик, які, можливо стануть гарною підмогою в проектах і допоможуть заощадити час команди, та й особисто ваше.

Ідея статті виникла досить давно. Так уже склалося, що пишу я на PHP, і найчастіше - бекенд-складові web-додатків. Пару років тому мені довелося познайомитися з CI. Я тоді потрапив в досить великий проект, де замовники розсудливо погодилися ще на самому початку запустити маховик CI і намагатися дотримуватися принципів і трендів (звичайно, в їх розумінні). Проект до моменту моєї появи вже існував, маючи наступний CI-склад: CruiseControl + Ant + phpUnderControl + phpUnit + PHP_CodeSniffer + Xdebug (Повний список посилань для ознайомлення з інструментами можна знайти в кінці статті).

Перше враження очима новачка в CI, до цього запускаємо юніт-тести перед кожним коммітов (так, там був SVN) з консолі вручну з налаштованим PHP_CodeSniffer в IDE і також запускаються вручну, було: «Клас," вколюють роботи а не людина "». Т. е. Хотілося розслабитися і блаженно переглядати звіти по білд. Звичайно, коли перше враження пройшло, з'явилися невеликі завдання щодо внесення змін до XML-конфиг phpUnderControl, несподівані падіння сервера після чергового билда, стало все виглядатиме не так райдужно, але позитивних моментів все одно спостерігалося значно більше, ніж негативних.

Час минав, хотілося додавати все нові корисності в процес CI: включення системи контролю версій бази даних в CI, автогенерація документації, підключення функціонального тестування з використання Selenium, більш розширений предпроцессінг коду, зав'язаний на рев'ю боард. Ось про останній і планую поговорити.

Предпроцессінг коду, джентельментскій набір

Досконалий код ... багато хто шукає цей Грааль, але реальність завжди вносить корективи, доводячи, що єдиного досконалості не буває. Але все ж бувають стандарти, стандарти кодування, як мінімум, яким весь код в проекті повинен відповідати. І така, здавалося б, проста річ часом все одно не дотримується. Так чому б не закликати можливі інструменти на допомогу?

Що і чому ж ми хотіли б перевіряти.

1. Перевірка синтаксису PHP, HTML, JS, CSS.

PHP - тут все просто, сам інтерпретатор PHP непогано справляється з цим завданням, php -l $ file.

HTML, CSS - з цим трохи складніше, існує безліч онлайн-сервісів, але більшість з нас пише комерційний код і освітлювати їм відкритих сервісах ... в загальному, це зовсім не те. Можна подивитися в бік сервісів на http://w3.org/ .

Для HTML:
http://validator.w3.org/docs/install.html
Можна завантажити вихідні коди, розгорнути сервіс у себе на сервері, за посиланням вище досить докладно описано, як це зробити. Тексти програм на Java.

http://www.bioinformatics.org/phplabware/internal_utilities/htmLawed/
Утиліта, створена компанією PHP Labware, цілком очікувано написана на PHP, остання версія підтримує HTML5-синтаксис (але потребує доопрацювання напилком). Також дозволяє не тільки проводити валідацію, а й готувати чистий Html на виході, що згодом може бути використано для організації онлайн Html редакторів, іншого.

Для CSS:
Тут варто згадати або навіть настійно рекомендувати використовувати препроцесори CSS ( SASS / SCSS , LESS ), Дуже багато тренд-frontend-рішення (Bootstrap, Foundation) використовують препроцесори коду. Вони дійсно дозволяють задати стиль ваших CSS, допомагають уникнути банальних помилок, дають можливість скоротити кількість коду, і ще багато всяких корисних речей. Спробуйте писати з використанням препроцесорів і зрозумієте, наскільки це спрощує роботу.

Список інструментів, які можуть стати в нагоді:
http://jigsaw.w3.org/css-validator/DOWNLOAD.html
Доступний для завантаження, опис присутній. Тексти програм на Java.

https://github.com/CSSLint/csslint
Для валідації CSS також можна використовувати цю окрему утиліту, хоча в останніх версіях PHP_CodeSniffer для неї написаний окремий Сніф. Досить гнучка і добре настроюється. Крім синтаксису, може виводити стильові помилки. Тексти програм на JS.

http://code.w3.org/unicorn/wiki/Documentation/Install
Поєднаний валідатор (HTML, CSS).

http://csstidy.sourceforge.net/
Швидше, бьютіфаер CSS, дозволяє перетворювати CSS, згідно набору стандартних правил, має можливість додавання своїх правил, широкий спектр налаштувань, доступний в 2 варіантах C ++ виконуваний файл і PHP бібліотека.

2. Перевірка стилю PHP, JS.

Для PHP:
PHP_CodeSniffer (Разом з PHP зараз може перевіряти JS, CSS використовуючи утиліти, описані в огляді). Заслужено може займати перше місце за популярністю, має великий набір налаштувань - предподготовленних стандартів. Написаний на PHP. Для реалізації свого стандарту можна отнаследоваться від існуючого і розширити своїми настройками, або написати стандарт з нуля. Загалом, річ, гідна окремої статті.
PHPMD - збирає інформацію про невикористаний коді (ще для цього можна використовувати PHPDCD), неоптимальном коді.

PHPCPD - любитель копипаста не пройде. Утиліта дозволяє знаходити повторюється код в ваших PHP-файлах.

Для JS:
Closure Linter - валідатор Стилю JS від Google, написаний на Python. Крім валідації, може видавати на вихід виправлений файл.

JSHint - перевіряє JS-файли на наявність помилок і потенційних проблем, для установки потрібні node.js і npm.

JSLint - ще один, і досить непоганий валідатор JS з перевіркою стилю, написаний на JS одним з ідейних лідерів фронтенда і JS як мови зокрема Дугласом Крокфорд.

JavaScript Lint - скоріше, розширена версія JSLint, від розробників Firefox. Написаний на C, доступний і скомпільований, і вихідним кодом.

Так, з інструментами ніби розібралися.
Але чому ж все-таки предпроцессінг, запитаєте ви, і як його готувати? Спробуємо розібратися.

Застосування, способи і практики:

Найпершим в черзі предпроцессінга коду у будь-якого розробника виступає IDE. У більшості IDE сьогодні є базові аналізатори коду, які, звичайно, вже є першим бар'єром (після прямоти рук розробника), що перешкоджає банальним ляпів при розробці додатків.

Але не завжди в web-розробці (і не тільки) код пишеться в IDE, яка попередить про помилку. Не завжди розробник звертає уваги на деякі попередження, та й IDE банально може не бути налаштована на, наприклад, правильне кількість прогалин або кодування файлів, які визначаються в Code Convection проекту. Читати потім такий код - не найприємніше заняття, а привести код проектів «у віці» до якогось стандарту взагалі не представляється можливим. Для запобігання цих прикрих моментів варто задуматися про впровадження практики предпроцессінга коду.

Виділимо такі різновиди:

1. Інтеграція в IDE.

Маю на увазі плагіни або вже входять в комплект IDE Хендлер утиліт, описаних вище. Варіант, цілком підходящий для розробки поодинці, і точно повинен бути у будь-кого. Головне - до початку роботи з свіжовстановленому IDE не забувати заглядати в налаштування і прописувати там шляху до утиліт, виставляти необхідний код Конвеншн. Ну і, звичайно, в разі командної розробки, варто зберегти експорт налаштувань, найбільш використовуваних учасниками проекту IDE, в репозиторій - заощадимо час інших на настройку проектних практик оформлення коду.

2. Pre-Commit (client side check)

Перевага цього методу і наступних - можливість централізації процесу контролю якості коду. Т. е скрипти, які виконують перевірки мо, гут лежати в окремому загальнодоступному репозиторії / гілці / папці, і тут вже не спишеш проблеми в коді на свіжу IDE.

Отже, хто ще не знайомий з системами хуков в системах контролів версій, - саме час познайомитися. Звичайно, децентралізовані системи контролю версій мають певну специфіку і в хуках (наприклад, в GIT на клієнтській стороні ви можете додавати свою кастомную перевірку і після кожного коміта, і до операції Push, починаючи з версії 1.8.2). Але спробуємо трохи узагальнити.

Для початку варто визначитися, що вже реалізовано в перевірках на рівні 1. Хоча якраз для перевірки на клієнтської частини на етапі хука цілком може перекривати перевірки на рівні IDE. І припустити, що буде краще перевіряти на етапі Pre-Update.

Можу запропонувати наступні перевірки на цьому рівні:

• Валідація JS, CSS (якщо планується використовувати PHP_CodeSniffer, див. Наступний етап). Т. е. Якщо ви помилилися в коді, JS, CSS, не будете витрачати час і ресурси сервера контролю версій на те щоб помістити ваші помилки в ньому.
• Валідація синтаксису PHP і перевірка коду на наявність застарілого і дублюючого коду, якщо використовується Git, звичайно, краще вішати цю перевірку на Pre-Push, т. К. Вона більш актуальна для великих обсягах коду, а всі ми віримо в «атомарность» коммітов.
• Якщо оточення і не дуже великий обсяг сховища дозволяють, можна повісити на Pre-Push і запуск юніт-тестів.
• Валідація формату commit-повідомлень (якщо про Git, у нього є окремий hook-тип - "commit-msg").
• Кожен може пограти з рівнем строгості перевірок. Зрозуміло, тут не варто сильно захоплюватися, але і особливо «ледачими» перевірки теж робити не варто. Взагалі, на даному етапі допускається пропуск перевірок, але тільки за допомогою спеціальних вставок в коді, які підтримують всі вищеописані утиліти, наприклад в PHP_CodeSniffer це буде виглядати так:

// @codingStandardsIgnoreStart class MyClassTest extends \ PHPUnit_Framework_TestCase {// @codingStandardsIgnoreEnd // ...}

Т. е. Все одно ці коментарі потім спливуть на етапі Review. І ось тоді, можливо, буде переглянутий ділянку коду або, принаймні, буде нагадування, що тут є відступ від правил, яке потім можна буде моніторити.

Додається на стороні сервера системи контролю версій, тут вже є можливість запускати перевірки, які залежать від оточення (особливо якщо розробка ведеться за участю віддаленого Web сервера, такі, як запуск юніт-тестів і т. П. Але тут вже все залежить від обсягів тестів : якщо часу на їх обробку йде багато, варто перенести перевірки в Build). ОБОВ'ЯЗКОВІ перевірки формату повідомлень, ACL-права на можливість змінювати певні директорії окремими користувачами, просто на можливість запису в окремо взяті гілки.

Окремо варто винести ряд перевірок, що запускається під час Build-процесу (Build як одна зі складових CI-процесу): запуск Автотест (Unit, Functional, UI), аналізатори коду (PHPMD, PHPCPD, т. Е. Що вимагають більшої кількості коду, ніж код на один Комміт), автодокументірованіе та інші корисності, які займають час і ресурси сервера CI. Добре що Build можна налаштувати на запуск, наприклад, вночі.

висновок

Це ще не висновки, а поки тільки висновок, - висновки можна буде знайти у 2-ї частини статті «Роль перед- підготовки коду в CI: частина 2. Доступні інструменти для автоматизації Review», яка поки в роботі. Але щиро сподіваюся, що хоч один з перерахованих вище інструментів зможе заощадити хоч трохи вашого безцінного часу.

посилання