1. Філософія. CI vs Bitrix
2. підтримка .git
3. Доставку замовляли?
4. А де ж тут Бітрікс?
5. Тематичні сторінки, меню
6. структура БД

Процес розробки сайту у всіх web-студій зазвичай складається з чітких і зрозумілих кроків: бриф, ТЗ, дизайн, верстка, програмування, тести. Після того, як сайт зданий, здається, можна розслабитися і прийматися за іншу роботу, але багато студій завжди дивляться в майбутнє - а що буде з проектом після закінчення робіт? Чи буде проект розвиватися? Адже сайт, як дитина, стає дедалі більше, вчиться чомусь новому, пропонує користувачам нові можливості. І кожному співробітнику хочеться продовжувати працювати над цікавими проектами вдолгую. Після здачі, проект переходить в стадію «підтримки» або / і «розвитку».

Підтримувати проект - досить копітка і непросте завдання: багато коротких завдань, бажання замовника бачити зміни на сайті якомога частіше, велика кількість фахівців, задіяних в роботі над проектом. Щоб проект не перетворився в збір мотлоху і розрізненого коду, існує філософія розробки - Continuous Integration (Безперервна інтеграція, CI).

Безперервна інтеграція (CI, англ. Continuous Integration) - це практика розробки програмного забезпечення, яка полягає в злитті робочих копій в загальну основну гілку розробки кілька разів на день і виконанні частих автоматизованих збірок проекту для якнайшвидшого виявлення та вирішення інтеграційних проблем (wikipedia.org) .

Статей про безперервну інтеграції web-додатків написана маса. Я ж хочу поговорити про CI в CMS 1С Бітрікс.

Філософія. CI vs Bitrix

Для початку потрібно зрозуміти що ми хочемо мати на практиці? Основна філософія CI полягає в наступному:

• Версійність коду;

• Версійність БД;

• Автоматичні складання нових версій проекту.

На практиці це означає:

• Один і той же код на production і develop версіях сайту;

• Одна і та ж структура БД на production і develop;

• Автоматичне перенесення змін на production (бажано взагалі без участі фахівця) за розкладом або за подією.

Що ж стосується Бітрікс, то важливі особливості CMS це:

• Недоторканність ядра;

• Недоторканність структури БД;

• Можливість поновлення ядра без наслідків;

• Технологія «Ермітаж», що дозволяє адміністратору сайту створювати розділи / сторінки на бою за допомогою візуального редактора;

• Налаштування компонентів (читай розділів сайту) зберігаються в файлах.

Що маємо на практиці при роботі з 1С-Бітрікс? Замовник може змінювати тексти на тематичних сторінках сайту самостійно. Може змінювати налаштування компонентів. Може оновити ядро. Та взагалі все може, якщо захоче. Шлях заборони: «Не чіпай, а то зламаєш!» - нам не підходить. Як нам відстежити всі, що робить замовник на сайті, і не втратити своїх змін? Давайте подивимося, що нам пропонує сам Бітрікс.

підтримка .git

Давним давно, коли Бітрікс був молодим і недосвідченим, публічні файли проекту лежали поруч з ядром, що дуже ускладнювало роботу - доводилося писати кілометрові .gitignore для виключення файлів, постійно стежити за новими модулями. Але настав 2013 рік і у Бітрікс з'явилася підтримка папки / local /, яка має перевагу перед папкою / bitrix / (ядро проекту). У цій папці ми можемо зберігати всі публічні файли сайту:

• / Local / templates - варіанти дизайну;

• / Local / php_interface - init.php;

• / Local / modules - модулі сторонніх розробників;

• / Local / components - компоненти сторонніх розробників;

• / Local / include / - папка для своїх доставок і платіжних систем.

Відмінно! Тепер можна не боятися «затерти» що-небудь не своє. Після довгих експериментів ми прийшли до такої структури проекту:

... www / site / / bitrix / - ядро ​​сайту / gitignore / - ми не хочемо, щоб файли від сюди потрапляли в репозиторій / current / - символьне посилання на папку / last_release /, DOCUMENT ROOT сайту / last_release / - корінь сайту / about / - публічна папка / bitrix / - символьне посилання на ядро ​​... / local / - папки з шаблонами, компонентами і т.д. / Upload / - символьне посилання на папку завантаження файлів / upload / - папка завантаження файлів

При цьому .gitignore наш виглядає наступним чином:

/ Nbproject / * .swp * .swo .idea / bitrix / upload / sitemap * * .tst * .zip * .log * .pdf * .xls * .txt * .html * .old gitignore gitignore / *

Доставку замовляли?

Ок, з репозиторієм розібралися, але як нам доставляти зміни на develop і production сервера? Якщо з dev сервером проблем не виникає (git pull), то на production можуть виникнути проблеми - не завжди є підтримка .git, замовник вносить зміни в код сайту (через візуальний редактор), як наслідок - маса конфліктів, кожен Комміт перетворюється в пекло. На допомогу приходять автоматичні збирачі коду.

Автоматичний збирач коду в вакуумі являє собою якусь службу, яка вміє:

• Відстежувати зміни в репозиторії;

• Робити git pull потрібної гілки;

• Архівувати файли;

• ssh.

Прикладів таких збирачів в мережі маса: Travis , Piplines from Bitbucket , TeamCity , Jenkins , Bamboo . Можна вибрати те, що підходить саме вам.

Ми пішли ще далі і вирішили автоматизувати і процес злиття гілок.

У нас є 2 основні гілки коду: master для production і гілка develop для develop версії сайту.

Ми в підсумку прийшли до наступної схеми: програміст Саша і верстальник Вова працюють над одним проектом. Програміст Саша переписує каталог, Вова «надолужує» нову форму зворотного зв'язку. Кожен з них працює в своїй гілці. Вова швидше впорався із завданням, коммітов стильові файли і виштовхує свою гілку в репозиторій. Його гілка в репозиторії змінюється, спрацьовує тригер, його гілка автоматично зливається з гілкою develop.

Develop гілка змінюється, спрацьовує тригер - складальник запускає процес деплоя: витягує гілку develop в свою папку поточного билда, архівує всі отримані файли і заливає архів на сервер в папку сайту. Після цього підключається по ssh, створює папку на сервері вище кореня сайту з назвою «release» і розпаковує в цю папку всі файли з архіву. Після цього в цій же папці створює всі символьні посилання, які необхідні для роботи проекту (посилання на ядро ​​bitrix, на папку upload і т.д.). На даний момент document root сайту дивиться на символьне посилання «current», тобто робота сайту не зупиняється ні на секунду! Після того, як посилання проставлені, збирач перейменовує папку «last_release» в «old_release», а папку «release», де лежить наш свіжий код - в папку «last_release».

І ось Вова вже через кілька хвилин (процес деплоя навіть на великих проектах займає 2-3 хвилини) милується новою формою на develop сайті і закриває завдання. Але невидимий оку складальник продовжує свою роботу. Після успішного деплоя на сервер, збирач зливає гілку develop з усіма іншими гілками розробників.

Програміст Саша нарешті закінчить задачу, закоммітіт свої зміни і спробує виштовхнути гілку. Але віддалений репозиторій не дозволить йому цього зробити. Спочатку попросить витягнути його свіжу гілку. Що Саша з радістю і зробить: зіллє гілки на локалі, вирішить конфлікти, якщо такі будуть, і з чистою совістю виштовхне свою гілку - процес деплоя почнеться з самого початку.

Тут ще варто сказати про вбудовану підтримку .git в сучасних IDE, наприклад, таких, як NetBeans. Саша взагалі не перемикається між вікнами - все відбувається в одному середовищі, нічого не потрібно запускати, натискати.

Після того, як замовник перевірив зміни і йому все сподобалося, гілка develop зливається з гілкою master і починається процес деплоя вже на бойовий сервер (за винятком злиття робочих гілок). Profit! Всі щасливі, всі задоволені.

А де ж тут Бітрікс?

включаються області

Перша проблема, з якою ми зіткнулися, - включаються області: номери телефонів, посилання на соціальні мережі, промо-тексти. Для всього цього використовуються включаються області ( bitrix: main.include ). Невже доведеться все ці області виносити в .gitignore? Щоб цього не робити, ми написали модуль - включаються області через БД. Принцип роботи зберігається - адміністратор сайту може правити включаються області через візуальний редактор, але інформація зберігається не в файл, а в БД, додатково вказується символьний код у налаштуваннях компонента, за яким ми однозначно визначаємо включається область. Тепер адміністратор може управляти включаються областями, зміни збережуться на сайті.

Тематичні сторінки, меню

Друга проблема - побудова меню і організація тематичних сторінок на сайті. Як відомо, меню в Бітрікс будується на основі спеціальних файлів. *. Menu.php - якщо замовник додасть в файл пункт меню, а ми про це не дізнаємося, при наступному білді ми просто затріть його зміни.

Проблему ми вирішили підключенням файлів. * Menu_ext.php, в яких структуру меню будуємо виходячи зі структури розділів і елементів спеціального «контентного» Інфоблоки. Розділ Інфоблоки = розділ сайту, елемент Інфоблоки = сторінка на сайті.

Замовнику говоримо створювати сторінки і пункти меню не через «сайт», а через інфоблок. Тим більше для нього це звичніше: товари, меню, новини - все створюється за одним принципом, не потрібно запам'ятовувати кілька різних алгоритмів дій.

Контент виводимо на сайті за допомогою компонента bitrix: catalog з налаштованим ЧПУ від кореня сайту:

"SEF_URL_TEMPLATES" => array ( "sections" => "", "section" => "# SECTION_CODE_PATH # /", "element" => "#SECTION_CODE_PATH # / # ELEMENT_CODE # /", "compare" => "" , "smart_filter" => "#SECTION_CODE_PATH # / # ELEMENT_CODE # / # SMART_FILTER_PATH # /",)

А в urlrewrite.php:

array ( "CONDITION" => "# ^ / #", "RULE" => "", "ID" => "bitrix: catalog", "PATH" => "/pages/index.php",),

Таким чином, всі сторінки, які фізично не знаходяться на сервері будуть відправлятися в цей компонент.

Але як нам бути зі сторінками типу / about / news /? Сторінка / about / це звичайна текстова сторінка, а / about / news / - розділ з новинами сайту з Інфоблоки новин. Для таких випадків нами написано властивість Інфоблоки, яке дозволяє визначити тип тематичної сторінки: текстова сторінка, зовнішнє посилання або компонент:

При цьому, двічі клікнувши на будь-який компонент, адміністратор отримує доступ до форми настройки компонента також, як і у візуальному редакторі на сторінках сайту:

Параметри компонента зберігаються у вигляді серіалізовані масиву в БД, а в шаблоні компонента bitrix: catalog в component_epilog.php виводимо збережений в БД компонент.

структура БД

Повернемося до нашого проекту. Спочатку програміст Саша працював над проектом не один - йому допомагав програміст Рома. Рома впроваджував новини, акції, текстові сторінки, Саша займався каталогом і магазином. Роботи велися одночасно. В процесі роботи і Саша і Рома повинні створити Інфоблоки, властивості цих Інфоблоки і т.д. Спочатку ми вирішували проблему «однаковості» БД для обох програмістів віддаленим підключенням до сервера, де лежить база даних. У кожного програміста свій код на локальне, а ось БД одна. Але виявилося, що не все так гладко: такий підхід гарний при розробці сайту - потім зробимо дамп і все виллємо на production. Коли проект вже знаходиться на бою, такий номер не пройде, доведеться руками створювати все нові Інфоблоки і властивості. Рішення, насправді, очевидно - міграції БД. Кожен програміст працює зі своєю локальною БД, а зміни доставляє на сервер у вигляді файлів-міграцій. Ми вибрали рішення від наших колег з компанії WorkSolutions - модуль міграції БД . Цей модуль відмінно нам підійшов: міграції створюються легко, все чітко і зрозуміло. Є підтримка консолі (наш збирач проектів дуже радий, так як йому додається додаткове завдання в кожному білді на міграцію бази даних).

Тепер процес трохи змінився: як тільки Саша коммітов свої зміни і намагається виштовхнути свою гілку, віддалений репозиторій просить його спочатку витягнути свою гілку і злити зі своєю локальною. Коли Саша це зробить, у нього з'являться нові файли міграції БД. Запустивши у себе на локалі оновлення бази даних через модуль, він отримає всі зміни БД, які вніс інший програміст.

Здавалося, все досить струнко і красиво, але при використанні міграцій БД відразу ж виникає проблема настройки компонентів. Як відомо, все спискові компоненти, які працюють з Інфоблоки вимагають вказівки ID Інфоблоки в налаштуваннях. ID у нас автоінкрементний, тому коли Саша і Рома в один і той же день в своїх локальних базах створять по Інфоблоки, у обох цих Інфоблоки буде ID = 1. Рома створить сторінку /news/index.php, там розмістить компонент новин з налаштуванням IBLOCK_ID = 1, Саша зробить те ж саме з каталогом, але вже в іншому файлі /catalog/index.php. Коли вони зіллють код в єдину гілку, наш збирач успішно проведе обидві міграції - вийде, що ми маємо на сайті 2 різних компонента, які працюють з одним Інфоблоки з ID = 1. Наприклад, першим створився інфоблок новин, а ось інфоблок каталогу з ID = 2 залишився не при справах. Подібна ситуація вийде і у кожного програміста на локалі, коли вони проведуть міграції.

Ми знайшли вихід у використанні констант. На подію «OnPageStart» ми запускаємо ось такий метод:

public static function Definders () {\ Bitrix \ Main \ Loader :: includeModule ( 'iblock'); $ Result = \ Bitrix \ Iblock \ IblockTable :: getList (array ( 'select' => array ( 'ID', 'IBLOCK_TYPE_ID', 'CODE'),)); while ($ row = $ result-> fetch ()) {$ CONSTANT = ToUpper (implode ( '_', array ( 'IBLOCK', $ row [ 'IBLOCK_TYPE_ID'], $ row [ 'CODE']))); if (! defined ($ CONSTANT)) {define ($ CONSTANT, $ row [ 'ID']); }}}

Тобто формуємо константи з типу Інфоблоки і його символьного коду (звичайно, при цьому у кожного Інфоблоки символьний код тепер заповнюється в обов'язковому порядку).

Тепер ми не використовуємо конкретні ID в налаштуваннях компонента - вказуємо константу, наприклад, IBLOCK_CONTENT_NEWS або IBLOCK_CATALOG_CATALOG. На develop версії, на production, у Саші і у Роми все Інфоблоки мають різні ID, але це ніяк не впливає на роботу сайту.

Звичайно, ми не стверджуємо, що така схема розробки ідеальна і підходить всім і кожному. У кожній студії свої особливості. Одного разу ми зрозуміли, що не хочемо використовувати програмістів для рутинної роботи - наші фахівці пишуть код і логіку, все інше можна перекласти на плечі автоматики. Спеціаліст тепер думає про проект, а не про вирішення проблем з «перенесенням». Упевнений, що ми не зупинимося на досягнутому, в майбутньому, напевно, з'являться і інші поліпшення в процесі розробки, про які ми обов'язково вам розповімо.