Відеобібліотека
Пошук у нотатках курсу Python мануфактура та спільних матеріалах з переходом на потрібну секунду.
Складіть однаковий список config keys для local, dev і CI без environment prefixes у коді.
Опишіть, хто створює test user, як він резервується для parallel worker і як відновлюється після failure.
Позначте зовнішні auth dependencies та окремо визначте production acceptance check і test-only seam.
Config matrix і state diagram без shared mutable user між parallel workers.
Для dev, staging, UAT та інших середовищ можуть існувати окремі локальні файли, і кожен із них має бути проігнорований. Якщо файл випадково додали до індексу, простого нового правила в `.gitignore` недостатньо: треба забрати його зі staged/tracked стану й тільки тоді перевірити ignore. Середовище не завжди визначається окремим доменом. Маршрутизація може залежати від path, cookie, custom header або feature flag; у production подібний механізм використовується для canary release. У тестах ці параметри мають бути явною конфігурацією, а не розкиданими константами. Ланцюжок розвитку у відео: hardcode → `.env` → структурований config → централізований config server. Перехід потрібен лише тоді, коли попередній варіант уже створює вимірювану незручність або ризик.
Device matrix слід будувати за production analytics: OS versions, vendor/model, screen resolution, update rate та частка foldable devices. Ще корисніше зіставити ці дані з користувачами, які приносять основний revenue, щоб бюджет на реальні пристрої відповідав бізнес-ризику. Стандартні platform components зменшують ризик, але Samsung, Huawei та інші vendors можуть мати власні UI/OS особливості й різну доступність Google services. Для dev build варто додати простий environment switcher між dev, QA, stage і production endpoints, а logs збирати через Xcode/Android Studio.
Один репозиторій запускається локально й у CI проти dev, preprod або інших середовищ. Сервіси можуть залежати від баз даних і зовнішніх third-party систем, інколи спільних для кількох середовищ. Локальний ноутбук часто отримує доступ до закритої мережі лише через VPN, тому той самий маршрут не можна автоматично перенести на hosted runner.
Код має звертатися до стабільних логічних ключів на кшталт `BASE_URL`, не до `DEV_BASE_URL` або `STAGE_BASE_URL` з ручним replace. Цільове середовище вибирає джерело значень, а не інші назви змінних. Завдяки цьому локальний і CI-запуск проходять тим самим шляхом. У CI значення зберігаються як захищені secrets/variables або як секретний файл. Репозиторій містить лише `.env.example` чи аналогічний шаблон зі структурою та без реальних credentials. Якщо використовується config server, CI може зберігати лише мінімальні credentials для доступу до нього.
iOS test builds поширюються через TestFlight, а build/distribution pipeline може використовувати App Center або platform developer consoles. Потрібно розрізняти dev build, прив'язаний до test/stage backend, і production-configured build, який перевіряють перед release. Тестувальнику рекомендовано мати read access до iOS/Android repositories, щоб бачити diff, перемикатися на feature branch і збирати зміни локально через Xcode чи Android Studio. Feature flags дають змогу вмикати функціонал для ролей, оточень або частини користувачів без розриву між backend і mobile releases. **Актуальність станом на 2026-08-08.** Visual Studio App Center завершив роботу 31 березня 2025 року; тимчасове продовження Analytics & Diagnostics закінчилося 30 червня 2026 року. Згадку у відео слід сприймати як історичну, а новий distribution/diagnostics workflow звіряти з актуальними сервісами платформи ([Microsoft Learn](https://learn.microsoft.com/en-us/appcenter/retirement)).
Runner повинен отримати base URLs, users, passwords, tokens та інші параметри без commit у репозиторій. У GitHub Actions значення можна зберігати як repository secrets/variables або прив’язувати до environments на кшталт DEV, STG і PROD. Environment-level значення зручні, коли ті самі ключі мають різні значення та правила доступу для різних середовищ. На реальному проєкті права на створення або зміну secrets можуть належати не автоматизатору. Це окрема залежність від власників репозиторію чи DevOps-команди, яку треба з’ясувати заздалегідь. Для малого набору параметрів не потрібно будувати складну config-систему: достатньо найпростішого контрольованого scope, який не розкриває секрети.
Несумісні версії SDK або gRPC-залежностей можуть спричинити crash лише під час відкриття конкретного екрана. Окремо розглядається SMS/OTP flow: повторні запити створюють реальні витрати й можуть стати resource-exhaustion атакою, тому потрібні rate limits, bot protection і безпечний test bypass. Dev build може передавати спеціальний header або environment configuration, щоб не надсилати реальне SMS і не викликати reCAPTCHA. Це приклад testability — архітектурної властивості, яку тестувальник має обговорювати з командою до автоматизації.