Технології

На цьому етапі ми працюємо з IT-відділом Клієнта: розробляємо API обміну, проєктуємо канали обміну даними. Результатом є односторонній або двосторонній обмін з ERP, AXAPTA, SAP та понад 20 менш відомими системами обліку та автоматизації.

Налаштуємо для вас CRM (AMOCrm або RetailCRM), після чого у вас будуть детальні звіти про продажі, сегментація за різними типами клієнтів для SMS та email-розсилок, а також аналітика рентабельності за джерелом реклами та типом товару/послуги.

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

Правило оцінки завдань

• Завжди надавайте оцінки для завдань

• Якщо завдання вже має оцінку від іншого розробника, переоцініть його, якщо ви не згодні з нею

Якщо ви працюєте над завданням з чужою оцінкою, ви погоджуєтеся з нею.

Правила розробки проєкту

• Розробка ведеться суворо в нашому gitlab

• Щодня комітьте та пуште результати роботи в репозиторій. Не повинно бути ситуацій, коли ви втрачаєте кілька днів роботи через такі причини, як «зламався комп'ютер», «переїжджав і забув скопіювати» тощо.

• Надсилайте мердж-реквести тімліду або старшому фронтенд- розробнику на рев'ю.

Вимоги до якості проєкту

Загальні вимоги

Chrome, Firefox, Safari, Edge

Точні версії браузерів, а також додаткові версії, слід запитувати у менеджера перед виконанням завдання, якщо вони не вказані в технічному завданні.

За замовчуванням має бути забезпечена підтримка двох останніх версій браузерів.

Сайт має бути адаптивним

• Логотипи мають бути у форматі SVG

• На продакшн та тестових середовищах: звичайні зображення повинні мати webp-версії, а їхній розмір має відповідати контейнеру (тег picture)

• Усі посилання повинні реагувати на :hover, :active та :focus

• При створенні статичних сторінок (наприклад, деталі Новин) більшість статичних елементів повинні бути стилізовані. Приклад: посилання, списки ul/ol, таблиці, заголовки.

• При створенні статичних сторінок зображення не повинні бути примусово розтягнуті на всю ширину. Додайте стилі до img: max-width: 100%, display: block, margin: 0 auto, padding: 10px, щоб зображення зберігали свій природний розмір, але не перевищували розмір контейнера статичної сторінки.

• Зміна розміру textarea не повинна ламати верстку

• Футер повинен «прилипати» до нижньої частини браузера, коли немає контенту або його дуже мало

• Пагінація слайдера не повинна ламатися, коли багато слайдів. Вона повинна рухатися або переходити вбік. Уточніть у менеджера та дизайнера, як це має бути для поточного проєкту

• Валідація форм повинна працювати

• Поле телефону повинно використовувати маску

• Кнопка «submit» форми повинна бути заблокована при першому кліку, щоб уникнути множинних відправок. Вона повинна бути розблокована після отримання відповіді від сервера.

• Виводити повідомлення про успішну/невдалу відправку форми

• Усі елементи інтерфейсу, які оновлюють свої дані без перезавантаження сторінки, повинні мати прелоадер

• Усі списки (Заявки, користувачі тощо) повинні мати пагінацію. Якщо це SPA, API має надавати дані з урахуванням пагінації

• При створенні живого фільтра (фільтра, що працює без натискання кнопки застосування) використовуйте переривання запиту

• Інформація про збірку проєкту та складну функціональність повинна бути описана у файлі README.md проєкту

• Створити попап на сайті, якщо в браузері клієнта вимкнені файли cookie. Це можна перевірити за допомогою JS через navigator.cookieEnabled. Повідомлення в попапі має бути таким: «Для коректної роботи сайту необхідно ввімкнути файли cookie в браузері.»

• Код повинен бути написаний відповідно до конфігурації ESLint проєкту

• Код повинен бути модульним. Назви модулів повинні відображати зміст контенту

• Бібліотеки встановлюються через yarn

• Для створення слайдерів використовуйте swiper

• Якщо проєкт працює з API, адреси доменів повинні бути розміщені в змінних середовища. Файл .env.

• Файл .env не повинен бути під git

• Створіть файл .env.example зі списком необхідних змінних середовища. Змінні повинні мати опис

• Відправка форм повинна працювати через FormData

• БЕМ

• Код повинен бути модульним. Назви модулів повинні відображати зміст контенту

Додаткові вимоги для SPA-проєктів

• Налаштування фільтра каталогу товарів повинні відображатися в URL з GET-параметрами

Додаткові вимоги для статичної верстки

• Верстка повинна проходити валідацію W3C

• Семантична верстка. Як мінімум, title, description та заголовки h1.

• Зображення повинні мати атрибути alt

• Назви та значення атрибутів (class="detail-page", id="news-list", тощо) повинні бути в стилі kebab-case

 

1. Перед початком роботи

Ми працюємо суворо з GIT. Жодна робота не ведеться без GIT.

2. Вимоги до налаштування GIT

На головному хості має бути активована гілка stage. Гілка master використовується лише для продакшн- хоста.
Використовуйте лише \n для розривів рядків.
Переконайтеся, що .gitignore налаштовано правильно.
Приклад налаштування .gitignore:

/upload/
/upload
/local/vendor/
/local/vendor
/web.config
/.htaccess
/robots.txt
/*.xml
*.swp
*.log
*.zip
*.tar
*.rar
*.gz

Якщо вся папка розміщена в .gitignore, але потрібно працювати з певним шаблоном, його можна повернути в git за допомогою: !templates/learning_10_0_0/
.gitignore можна змінювати та розширювати залежно від потреб проєкту.
Скрипти налагодження, журнали, медіафайли, зареєстровані в базі даних, та інші подібні файли не повинні потрапляти до GIT.
Усі розробки переглядаються тімлідом/старшим програмістом проєкту. Уточніть головного програміста у менеджера. Розробник не змінює гілки master, stage, layout-master, layout-stage, а також гілки, створені іншими розробниками, оминаючи тімліда. 1 розробник - 1 хост. Якщо над проєктом одночасно повинні працювати кілька розробників, кількість хостів на проєкті повинна дорівнювати кількості розробників + 1 (загальний хост, куди зливаються всі зміни). Керівник проєкту контролює це та повинен бути поінформований, якщо вимога не виконується.
Усі розробки розробників спочатку зливаються в stage, потім у master. Нічого не зливається безпосередньо в master. Усі нові гілки для нових завдань починаються з поточного stage. Перенесення змін на продакшн здійснюється тімлідом проєкту або його старшим програмістом проєкту.

3. Перенесення розробок та деплої

3.1. Обов'язкове злиття всіх розробок у репозиторій у вівторок та четвер

Щовівторка та щочетверга всі розробки мають бути злиті у віддалений репозиторій. Розробки зливаються по мірі готовності та обов'язково у вівторок та четвер, навіть якщо блок не завершено. Відповідальний за контроль — тімлід. Виконавець цієї події — розробник. Розробник повинен запушити всі розробки в репозиторій до 19:00 у вівторок та четвер. Тімлід, залежно від потреб проєкту, може змінювати частоту обов'язкових злиттів у репозиторій. Це може бути частіше, але не рідше. Якщо немає додаткових вимог від тімліда, обов'язкові злиття в репозиторій відбуваються у вівторок та четвер. За порушення цієї вимоги буде накладено штраф. Якщо між термінами злиття був безперервний простій, ця вимога не застосовується.

3.2. Деплої на продакшн

Дні деплою - пн, вт, ср, чт з 10:00 до 16:00. Пт з 10:00 до 15:00. Винятки можливі лише для термінових завдань та за погодженням з керівником проєкту.

4. Створення та оновлення нової гілки перед початком нового завдання

Правила найменування гілок описані в розділі 6. Оновіть локальну гілку stage з віддаленого репозиторію. Створіть локальну гілку розробки з stage.

5. Звіт про виконану роботу та підготовка до перенесення розробок на препродакшн для перевірки

Після завершення розробок необхідно виконати git pull ... у поточну гілку з гілки stage віддаленого головного репозиторію, щоб уникнути конфліктів.
Запуште гілку з розробками за допомогою git push ... в ту саму гілку віддаленого репозиторію.
У віддаленому репозиторії створіть мердж-реквест у stage тімліду або старшому на проєкті, якщо вони відповідають за злиття.
Прикріпіть у пункті чекліста або в коментарі до завдання, якщо його немає, посилання на мердж- реквест з розробкою та коментар щодо суті розробки.
Повідомте тімліда або старшого на проєкті, якщо вони відповідають за злиття, для перегляду роботи та прийняття мердж-реквесту або повернення його на доопрацювання.
Якщо все добре, перевірте роботу на головному тестовому середовищі.
Тестування розробок проводиться лише на головному тестовому середовищі!
Примітка: На розсуд тімліда проєкту оновлення гілки може здійснюватися з гілки master замість stage.

6. Правила перенесення розробок на продакшн

Якщо виконане завдання необхідно перенести на продакшн:
Необхідно виконати git pull ... з гілки master віддаленого головного репозиторію, щоб уникнути конфліктів.
Створіть новий мердж-реквест, але цього разу зливаючи в master.
Прикріпіть у пункті чекліста або в коментарі до завдання, якщо його немає, посилання на мердж- реквест з розробкою та коментар щодо суті розробки.
Також повідомте тімліда або старшого на проєкті, якщо вони відповідають за злиття, хто перегляне, прийме зміни (тімлід та менеджер) та запушить зміни на продакшн.
Перевірте функціональність на продакшні.
Для коректного перенесення важливо знати:

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

7. Правила найменування гілок

7.1. Правильне найменування гілок

7.1.1. Якщо чеклісти великі

Назви гілок повинні містити номер завдання та номер чекліста, за яким ведеться робота, та пункт чекліста.
Таким чином, при виконанні завдання гілка виглядатиме так:
ih/taskNumber-Checklist/briefTaskDescription

• ih означає inhouse, тобто штатний співробітник.
• os означає outstaff, тобто підрядник.
• taskNumber - завжди вказуйте номер завдання.
• Checklist - завжди вказуйте номер чекліста.
• briefTaskDescription — це 2 - 4 слова.

Приклад правильно названої гілки:
ih/54361-3/updateCatalogStyles
У гілках важливо писати номери завдань та чеклістів у комітах:
git commit -m "task-22333, buglist-1,2"

7.1.2. Якщо чеклісти малі та не потребують окремого перенесення

Назви гілок повинні містити номер завдання.
Таким чином, при виконанні завдання гілка виглядатиме так:
ih/taskNumber/briefTaskDescription

• ih означає inhouse, тобто штатний співробітник.
• os означає outstaff, тобто підрядник.
• taskNumber - завжди вказуйте номер завдання.
• briefTaskDescription — це 2 - 4 слова.

Приклад правильно названої гілки:
ih/54361/updateCatalogStyles
У гілках важливо писати номери завдань та чеклістів у комітах
git commit -m "task-22333, buglist-1,2"

7.2. Найменування гілок з багами

7.2.1. Найменування гілок з багами для одного пункту чекліста

ih/54361-3/bugFix

7.2.2. Найменування гілок з багами для всього завдання

#Ця гілка використовується для масових виправлень багів
ih/54361/bugFix

7.3. Крайній випадок у найменуванні гілок

У випадку, якщо робота з якоїсь причини не прив'язана до конкретного завдання, найменування таке:
ih/yearday/briefTaskDescription
Приклад альтернативно названої гілки, якщо для неї немає завдання:
ih/2107/checkoutRefactoring

8. Правила найменування комітів

Назви комітів повинні відображати суть виконаної роботи.
Назва коміту повинна включати номер завдання та номер пункту завдання.
Приклад:"54361-1 import elements to offers iblock" Де 54361-1 - це номер завдання та номер пункту, розділені дефісом.

9. Якщо відредагований файл неправильно відформатований (PSR, Line Breaks)

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

• Перед початком роботи відформатуйте файл відповідно до правил написання коду (у PHPStorm використовуйте [CTRL] + [ALT] + L) та закомітьте, переконавшись, що PHPStorm правильно налаштований для PSR та версії PHP. У коміті вкажіть, що це форматування.
• Починайте працювати лише після коміту форматування.

10. Робота з версткою та стилями

Backend-розробник не редагує безпосередньо стилі чи верстку у backend-гілці. Для роботи з версткою використовується окремий репозиторій. Дотримуйтесь правил роботи з інструментами збірки.

11. Уточнення до правил перенесення змін на продакшн (окремий випадок до пункту 5)

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

• Усі коміти (хеші), пов'язані з виконаним пунктом завдання, повинні бути перелічені.
• Перенесення на продакшн слід здійснювати цілими блоками (логічно завершеними блоками), а не частинами, щоб уникнути конфліктів та багів через перекриття комітів.
• Перенесення слід здійснювати за допомогою гілок релізу, наприклад: release/20210408, де 20210408 - це сьогоднішня дата.
• Розробки слід переносити до гілки релізу за допомогою команди: git cherry-pick commit.

Ви повинні знаходитися в гілці, куди хочете перенести коміт, використовуючи команду git cherry-pick commit.
Якщо коміту, який потрібно перенести, немає у вашому локальному git, спочатку необхідно підтягнути зміни з інших гілок до вашого git (команда у вашій гілці з інших гілок нічого не зіллє) git fetch origin git fetch - підтягує дані у ваш локальний репозиторій, але не зливає їх з вашими розробками та не змінює те, над чим ви зараз працюєте. Вам необхідно вручну злити ці дані з вашими, коли ви будете готові.

12. Корисні команди для тімліда

12.1 Команда для додавання нових змін до останнього коміту

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

git add file  
git commit --amend --no-edit

13. Інше

У будь-яких незрозумілих ситуаціях звертайтеся до документації GIT першоджерела. Якщо рішення не знайдено, зверніться за допомогою до колег (програмістів, тімліда).

Верифікація (перевірка) експлуатаційної документації від постачальника, спільноти на наявність інформації щодо підтримки та оновлень, включаючи виправлення вразливостей.

Ідентифікація та аутентифікація

Для ідентифікації користувачів під час доступу кожному користувачеві повинен бути присвоєний унікальний персональний ідентифікатор.

Доступ користувачів повинен бути реалізований через парольну аутентифікацію.

Необхідно забезпечити захист зворотного зв'язку при введенні аутентифікаційної інформації.

Локальна політика паролів повинна відповідати таким вимогам:

• політика складності паролів;

• збереження історії паролів;

• налаштування терміну дії паролів;

• можливість змінити пароль при першому вході;

• можливість користувачам самостійно змінювати свій пароль

Можливість інтеграції з системою керування ідентифікацією.

Авторизація користувачів для доступу повинна відбуватися лише після завершення процедур ідентифікації та аутентифікації.

Підтримка механізмів багатофакторної аутентифікації.

Керування доступом.

Керування доступом

Реєстрація та облік подій інформаційної безпеки

• реєстрацію дати та часу спроб входу/виходу користувача з системи;

• реєстрацію часу запуску/зупинки компонентів;

• реєстрацію змін у привілеях користувачів;

• реєстрацію змін конфігурації;

• реєстрацію дій адміністратора;

• реєстрацію дій користувачів

Захист програмного забезпечення

Забезпечення цілісності

Мережева безпека

Криптографічний захист

Контроль НДВ