Python мануфактураJavaDesign Patterns для автоматизаторів

Терміни, нюанси та джерела

Java · Додаткові матеріали · 10:55–12:50

Окрема branch для зміни

Зміни для окремого завдання виконуються в новій branch, створеній від актуальної основної гілки. При створенні варто одразу checkout на неї, після чого перевірити поточну branch перед commit. Це ізолює роботу та спрощує подальший review.

Публікація Java-проєкту на GitHub →

Java · Додаткові матеріали · 12:50–14:37

Commit і push

Commit зберігає перевірений знімок змін у локальному repository. Перед push ще раз перевіряються target branch, commit message і файли в diff. Push передає локальні commits до remote repository. Демонстраційний push у відео завершується SSH permission error, що показує окрему вимогу: SSH URL потребує налаштованого SSH key і доступу до repository.

Публікація Java-проєкту на GitHub →

Java · Сесії: AMA та PMP · 39:10–47:39

Доменні межі, кілька застосунків і один стартовий repository

Великий продукт може мати B2C, B2B, back office, tool-sharing або branch-office застосунки зі спільним core. Структуру automation варто повторювати за реальними domain/app boundaries, а common-код піднімати лише тоді, коли він справді спільний. Для нового automation effort рекомендовано починати з одного repository: розділити усталену систему пізніше простіше, ніж одразу координувати кілька репозиторіїв без перевіреної потреби. Один repository також полегшує справжні end-to-end flows через кілька доменів.

Неймінг та структура automation-проєкту →
Запитати в чаті про «branch» →