CheIT Dev Work Flow

Cхема роботи

Cхематично наш flow можна подивитись нижче↓ за посиланням можна подивитись тут

Відгалуження

*MR - merge request

*PR - pull request

*CR - Code Review

Основні гілки

На всіх проектах завжди присутні 2 основні гілки master і stage.

master- основна гілка проекту. З неї починається будь-яка нова вхідна задача, з неї вона потрапляє на production сайт (цей процес ще поки що не автоматизований). У більшості випадків ми відштовхуємося від того, що код у гілці master і код на production сайт однаковий.

stage- гілка для тестування виконаних задач. Код із цієї гілки протягом кількох хвилин після MR автоматично потрапляє на staging сайт.

production- спеціальна гілка для того, щоб код автоматично потрапляв потрапив на production сайт.

Інші гілки

features/JS-8- основна гілка окремої задачі. Назва гілки береться строго з коду задачi в Jira.

bugfix/JS-8- основна гілка окремої задачі де треба пофіксити баг, який було знайдено на сайті.

Назва гілки береться строго з коду задачi в Jira. Знайти цей код можна тут:

Порядок роботи

1. На Вас як розробника в Jira приходить задача в колонку TO DO або OPEN - її потрібно перевести в колонку IN PROGRESS

2. У локальній копії сайту створити нову гілку з гілкиmaster (наприклад features/JS-8)

3. Виконати задачу та опублікувати гілку features/JS-8 з коммітом у репозиторії проекту.

4. Зробити MR гілкиfeatures/JS-8 в гілку stage:

   • features/JS-8 не видаляємо!

     

   • після чого запуститься процес автоматичного деплою на staging сайт. Перевірити це можна в розділі Built → Jobs:

     

5. Перевірити працездатність виконаної задачі на staging сайті (за необхідності створити сторінку\пост, заповнити тестові дані тощо)

6. Якщо на staging сайті ввімкнено кешування (зазвичай це плагін WP Rocket), то необхідно:

   • очистити кеш на всьому сайті (якщо це мультисайт - то необхідно очистити кеш на всіх сайтах окремо)

   • відключити плагін кешування (тільки в тому випадку, якщо плагін не важливий для поточного завдання)

7. Змінити статус задачi на CODE REVIEW (у деяких випадках для CODE REVIEW може бути окремий стовпчик)

   • Обрати виконуючим відповідального за перевірку коду (CR) (зазвичай це Тім\Тех лiд)

   • У коментарях залишити:

     • посилання на MR у гілку stage

     • посилання на сторінку staging сайту, де велася робота

     • додати коментар, якщо необхідно на щось звернути увагу.

8. Після виконаного CR може бути 2 варіанти:

   • Задача буде повернута на доопрацювання. У коментарях буде вказано причину цього + у самому MR будуть вказане посилання на код, який необхідно змінити\поправити\доопрацювати. У такому випадку задача залишається в колонці CODE REVIEW. Робочу процедуру необхідно буде повторити:

     • У локальній копії сайту в гілці features/JS-8 доопрацювати задачу

     • Зробити новий коміт і опублікувати його в репозиторії

       • У назві коміту(ів) потрібно додати строку “After CR day.month: message”.
         Наприклад After CR 13.09: fixing news section

     • Зробити MR у гілку stage

   • Задача успішно пройшла CR. Необхідно буде зробити наступне:

     • Зробити MR features/JS-8 у гілку master

     • Цього разу необхідно поставити галочку “Delete source branch…”, щоб гілка features/JS-8 була видалена пiсля завершення MR.

     • Переконатися в успішному (безконфліктному завершенні) MR.

     • Перемістити задачу в колонку READY FOR QA (інколи READY FOR TESTING)

     • Призначити виконавцем PM проекту

   • У разі успішного проходження QA, задача буде переміщуватися далі по дошці Jira (за це вже відповідає PM або QA)

   • Якщо QA знайде помилки, то необхідно буде повторити робочий цикл: задача переміщується в колонку TO DO або OPEN, і Ви призначаєтесь виконавцем.

Робота з гілкою production

Якщо в гіт репозиторії є гілка production - це означає те, що для цього проєкту налаштовано автоматичний деплой на production сайт. У більшості випадків це зроблено за допомогою протоколу LFTP.

Для того, щоб усе спрацювало, Вам необхідно просто MR з гілки master в гілку production. Статус деплою буде доступний в розділі Built → Jobs (з тегом deploy_production):

Список типів робіт, які необхідно передавати на CR

1. Якщо повністю була закінчена сторінка з декiлькома блоками

2. Блоки, які включають в себе роботу з js бібліотеками (slider, swiper і т.д)

3. Наявність ajax функціоналу

4. Наявність форм у блоці або на сторінці

5. Будь-яка API інтеграція

6. Будь яка бага, яка прийшла від клієнта!