Найпоширеніша схема здачі сайту виглядає так. Розробник відкриває кілька сторінок, клікає по меню, переконується, що нічого не розсипалось, і пише замовнику «готово». Це називають перевіркою. Насправді це огляд, і в нього є два вроджені дефекти. Він охоплює те, про що згадали, і залежить від настрою людини о шостій вечора в п’ятницю.
Звідки взялися гейти
У фінансових системах питання «чи можна це випускати» надто дороге, щоб залишати його на розсуд конкретного інженера. Тому там з’явився механізм релізних гейтів — набір автоматичних умов, які збірка зобов’язана виконати, щоб отримати право на публікацію. Гейт не має думки. Він або пропускає, або ні.
Ключова властивість гейта не технічна, а організаційна. Він знімає з людини необхідність бути дисциплінованою в найгірший для цього момент — коли строк горить, а замовник чекає. Модель релізних гейтів як інструмент управління операційним ризиком я описав у доповіді на 8-й Міжнародній науковій конференції «Інформаційні та інноваційні технології в XXI столітті» і застосовую її у власній роботі.
Що конкретно перевіряється перед передачею
Мій конвеєр проводить кожну збірку через ізольоване середовище з тими самими обмеженнями, що й на робочому сервері. Перевіряються, зокрема, такі речі.
Швидкість. Google Lighthouse у мобільному профілі, медіана трьох прогонів. Медіана тут принципова — одиничний замір легко дає розкид у десятки балів через шум середовища, і саме на цьому будують красиві скриншоти.
Доступність. Машинна перевірка за наборами правил WCAG 2.1 рівнів A і AA плюс ручний прохід усього сайту з клавіатури. Сканер ловить приблизно третину проблем доступності, і чесно про це попереджає. Наприклад, контраст нетекстових елементів чи зрозумілість тексту посилання автоматика не бачить взагалі.
Верстка на вузькому екрані. Кожна сторінка перевіряється на ширині 320 пікселів. Горизонтальне прокручування — це порушення, а не косметична дрібниця, бо на нього натикаються люди з увімкненим збільшенням.
Заголовки безпеки й політика вмісту. Перевіряється не наявність файлу з налаштуваннями, а те, що сервер їх реально віддає.
Вразливості залежностей. Склад бібліотек звіряється з відкритими базами вразливостей. Не раз перед здачею, а щодня, поки триває підтримка, бо відповідність деградує сама, без жодних змін у коді.
Типізація і збірка. Помилки типів валять збірку. Це дешевий спосіб не отримати падіння на робочому сервері через одруківку.
Урок, який ледь не коштував мені репутації
Під час розробки власного інструмента аудиту я отримав показовий збій. Браузер для автоматичних проб не запустився, збір фактів мовчки повернув порожній результат, а правила чесно відрапортували «не відповідає» за трьома критеріями, які на сайті насправді були виконані.
Тобто інструмент був готовий звинуватити чужий сайт у порушенні через власну помилку. Після цього кожен набір правил у мене обгорнутий перевіркою — якщо збір фактів не виконався, критерій повертає «перевірку не виконано», а не «не відповідає». Різниця між цими двома формулюваннями і є різницею між аудитом і галасом.
Чому це стосується сайту школи
Може здатися, що банківські практики для сайту закладу освіти надлишкові. Логіка зворотна. У банку є відділ, який помітить проблему за годину. У школі немає нікого, хто помітить її взагалі — доти, доки хтось не поскаржиться або сайт не почне роздавати чужі посилання.
Саме тому те, що у великій компанії страхується людьми, у маленькій установі має бути застраховане автоматикою. Це не преміальна опція, а єдиний спосіб зробити систему, яка не вимагає постійної уваги.
Що входить в основу кожної системи, а що додається за потребою, розписано на сторінці надійності — там видно, що змінює кожен контур у житті закладу.