Шлях коду від голови програміста до продакшену

💡 Усі статті, обговорення, новини для початківців — в одному місці. Приєднуйтесь до Junior спільноти!

Привіт! Мене звати Володимир Обрізан, я кандидат технічних наук, директор компанії Design and Test Lab. Цей матеріал ми написали в співавторстві з моєю колегою Senior Project Manager Оксаною Павловською.

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

Репозиторії, або Де і як зберігається код

Найголовніше, що треба знати про код (source code) — це звичайний текстовий файл. Щоб писати та редагувати код, можна використовувати будь-який текстовий редактор, наприклад, NotePad. Але розробники використовують інтегроване середовище розробки (IDE — Integrated development environment), яке поєднує в собі функції текстового редактора з багатьма іншими функціями: компіляторами, відладчиками, перевірками синтаксису тощо.

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

Розробка проєкту зазвичай виконується командою розробників, які можуть працювати в одній кімнаті, а можуть й віддалено в різних куточках світу. Як мій код з мого компʼютера потрапить до мого колеги з іншого міста? Звичайно, я беру дискету, копіюю туди файли та надсилаю дискету Новою Поштою, яка працює у 200 країнах світу.

Тут би я подивився на ваші обличчя, якщо б я це серйозно розповідав особисто на конференції 🙂. Жартую! Обмін кодом розробники роблять за допомогою інтернету. Програмісти використовують спеціальні системи розподіленого контролю версій коду (distributed version control system). Доробивши своє завдання, я відправляю ці зміни до центрального сервера з кодом, який називається репозиторій (source code repository).

А чому їх називають системами контролю версій? Тому що ці системи не лише зберігають файли, як це робить, наприклад, Dropbox або Google Drive. Системи контролю версій зберігають ще й історію всіх змін до коду. Учора була одна версія коду, сьогодні я додав нові функції, виправив помилки — і отримав уже нову версію коду.

Памʼятаєте, як колись у студентські роки потрібно було носити на флешках курсові до викладача? А коли викладач казав щось виправити, то всі робили назви файлів «курсач 1.doc», «курсач 2.doc», «курсач 3.doc», і під кінець семестру на цій дискеті було 20-30 файлів, які відрізняються цифрою наприкінці імені файлу. Програмісти таким не займаються, тому що система контролю версій робить все за них. Якщо я зберіг окрему версію, вона пам’ятає, що було сьогодні, вчора, позавчора, навіть якщо я зробив 5-6 версій за день. Якщо я зробив щось погане з кодом, то я можу піти та переглянути попередні версії.

Як код потрапляє до репозиторію

Ґіт (git) — найпоширеніший стандарт для обміну кодом. Існує декілька імплементацій цього стандарту для організації репозиторіїв у хмарі або на власному сервері: Atlassian BitBucket, GitHub, Microsoft Azure, Gitlab тощо. Особисто я використовую BitBucket.

Звичайно, мені як програмісту вистачає 5 команд протоколу git, щоб працювати з репозиторієм:

• git clone (клонувати) — використовую для того, аби код потрапив на мій жорсткий диск (коли я приходжу на проєкт, у мене ще нема його коду);
• git commit (комітити) — використовую для фіксації змін на моєму локальному репозиторії;
• git push (пушити) — використовую для відправки моїх локальних змін коду на сервер, у центральний репозиторій;
• git pull (пул) — використовую для стягнення змін із центрального серверу. Це важливо, адже зміни могли додати інші члени команди (я не один, хто працює з кодом);
• git branch (бранч) — використовую для того, щоб зробити окрему гілку коду.

Доробивши задачу, я використовую команду git push — і всі мої зміни потрапляють до центрального репозиторію, де з ним може ознайомитись вся команда.

Про гілки коду та pull requests

Щоб не заважати один одному, програмісти роблять зміни у окремих гілках коду (branch). Існує декілька загальних гілок коду, наприклад:

• dev або main — це основна гілка, де зберігається гарна версія коду для поточної розробки;
• release — це гілка, де зберігається остання релізна версія коду;
• інші гілки, які команда розробки може зробити для своїх потреб.

Сучасна розробка коду — це про надійний код. Тож аби код з моєї гілки потрапив до основної гілки, треба щоб його перевірили інші програмісти. Запушивши код, я роблю pull request — запит на злиття коду з моєї гілки до основної гілки dev.

Якщо інші програмісти подивились мій код і критичних зауважень немає, то можна робити злиття та йти пити каву. А якщо зауваження є — то я випʼю каву, а потім піду виправляти ці зауваження на своєму компʼютері, робити новий пуш і новий pull request.

Від репозиторію до білду

Код розробляється не для того, аби лежати десь тихенько в гілках. Нам треба, щоб код хтось протестував, перевірив, потім його подивився замовник, схвалив роботу та заплатив гроші.

Далі треба зробити білд у білд-артефакт. У різних мов програмування цей процес може бути різним. Наприклад, якщо нам треба створити бекенд вебсервіс за допомогою мови Python, то необхідно зробити вебсервер, який буде виконувати ці інструкції. Білд-артефакт — це програма, у якій є всі бібліотеки, конфігураційні файли та коди програми, і вона вже готова для запуску.

Білд (build, збірка) — це процес, під час якого ми беремо версію коду, компонуємо його, завантажуємо необхідні бібліотеки та робимо всі потрібні конфігурації цього коду. Зрештою отримуємо програму, яку можна деплоїти, а далі тестувати або робити демо. Білд або збірка використовуються у двох контекстах: дієслово збирати (to build), коли ми отримали версію від розробників та виконуємо процесс збірки; іменник (a build) — це результат білду, білд-артефакт. Тобто «я зробив білд та цей білд вже на сервері».

Про деплой

Код з репозиторію білдиться, що далі? Існує декілька репозиторіїв для білд-артефактів. Наприклад, для вебзастосунків ми використовуємо систему Docker і робимо docker-образ. Результат білду — це docker-образ певної версії, який зберігається у docker-registry. У цьому білд-артефакт-репозиторії ми зберігаємо не код проєкту, а вже готовий образ застосунку.

Деплой (deploy) — це процес, коли ми версію застосунку доставляємо до тестувальників або користувачів. Наприклад, у вебзастосунках, аби білд потрапив до тестувальників або замовника, треба щоб docker-образ потрапив на сервер. А у мобільних застосунках є етап публікації: ми відправляємо версію в App Store, а тоді вже користувачі, тестувальники або замовник встановлюють на телефон цей застосунок.

Що таке CI/CD

Continuous integration — це безперервна інтеграція продукту. Коли працює розподілена команда, то компоненти робляться окремо, і під час злиття коду в основу гілку треба перевірити тестами, що все працює добре. Коли я відправлю свій код на код-рев’ю, сервери інтеграції одразу запустять ще тести, наприклад, інтеграційні. Можна відразу зробити автоматичний білд, деплой на тестове середовище.

Continuous delivery — безперервна доставка версії застосунку до кінцевих споживачів. Ми не чекаємо місяць, поки зберемо всі зміни до коду та зробимо нову версію продукту. Нам треба робити delivery дуже швидко та часто.

Environments, інстанси

Щоб до замовника або споживачів потрапив надійний застосунок, нам треба все перевірити. Та тестів багато не буває 🙂. І перед тестуванням з користувачами нам треба десь провести перевірку. Спеціальний простір для цього називається тестове оточення або інстанс (test environment or instance). Інстанс — це своєрідний екземпляр застосунку. У хмарі ми можемо виконати два, пʼять або більше цих інстансів, а тоді робити все що завгодно. Наприклад, у нас є команда тестувальників однієї версії, а є інша команда тестувальників іншої версії. І для розробників робимо різні інстанси, щоб ніхто нікому не заважав.

Коли тестувальники тестують застосунок, пов’язаний з платежами, не хотілося б ризикувати реальними грошима. Тому в деяких оточеннях ми підміняємо справжню платіжну систему засобом, який списує гроші, але віртуально, і тестувальник не витрачає реальні гроші. Ці оточення відрізняються сервісами, тому що в тестовому оточенні не буде справжніх платежів: наприклад, імейли можуть не надсилатися (або щось інше, що може бути в реальному застосунку).

Існує декілька оточень. По-перше, це development-оточення — остання версія застосунку (тобто всі розробники бачать, що відбувається).

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

Production-оточення — це оточення, яке підімкнене до всіх реальних систем платежів, відправки пошти тощо, та з яким цілодобово працюють кінцеві споживачі.

Підсумки

Ще раз коротко запишемо шлях, який проходить код:

• з голови за допомогою рук код потрапляє на жорсткий диск комп’ютера;
• за допомогою системи git я фіксую зміни;
• за допомогою команди git push відправляю цей код на віддалений репозиторій;
• усі зміни я роблю в окремій гілці коду;
• коли я все закінчив, роблю pull-request, аби інші програмісти перевірили його для майбутнього злиття в гілку dev/main;
• continuous integration запускає тести, статичну перевірку коду та робить білд;
• розгортаю застосунок на development-інстансі, щоб інші розробники бачили застосунок, що працює;
• після тестування і ухвалення рішення про майбутній деплой, я деплою на stage-оточення або production-оточення.

Чи це виглядає складно? Мабуть, так.

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