#2 Файли проєкту
Вступ до найкращих практик управління проєктами в еру штучного інтелекту.
Отже, тепер ми зрозуміли загальний огляд ШІ. Однак, щоб розпочати розробку, нам спочатку потрібне середовище. Давайте налаштуємо середовище розробки, орієнтоване на використання ШІ. Перш за все, нам потрібно вирішити, як керувати файлами проєкту. Просте спільне використання файлів несе в собі ризик необхідності переписувати код з нуля в разі помилки. Это залишається вірним навіть при використанні ШІ, тому контроль версій та управління проєктами є невід'ємними у сучасній розробці.
У минулому розробка починалася з простого обміну файлами (NFS або NetBIOS), який потім еволюціонував через CVS (приблизно з 1990 року) → VSS (з ~1995 року) → Subversion (з ~2000 року) → Git (з ~2010 року) (ці часові межі є приблизними). Я підготував і налаштував середовища для кожного з цих етапів. Історично налаштування середовищ репозиторіїв (одиниць для зберігання та управління файлами проєктів разом з історією оновлень) вимагало ручного встановлення або купівлі, а також створення середовищ резервного копіювання, що було великим завданням. Сьогодні беззаперечним вибором є GitHub. (Оскільки він безкоштовний, лол)
【Про GitHub】
Раніше GitHub обмежував безкоштовні акаунти одним приватним репозиторієм, але тепер це обмеження знято. Крім того, GitHub Actions пропонує до 2000 безкоштовних хвилин на місяць, а зберігання є безкоштовним до 500 МБ.
Це чудово. Ми живемо в чудову епоху. Звичайно, ви також можете запустити контейнер Gitea через Docker, щоб створити локальне Git-середовище. Для великих проєктів, де я не використовую CI/CD, я керую ними на своєму локальному сервері.
<Що таке CI/CD?>
Це важлива філософія у розробці на основі ШІ та без коду. У минулому системні аналітики (SA) аналізували бізнес-операції та збирали вимоги, системні інженери (SE) створювали специфікації та вимоги до тестування, а програмісти (PG) писали код (відомо як каскадна модель або waterfall). Порівняно з цим, сьогоднішній день здається зовсім іншим світом. Озираючись на високу вартість повернення до попередніх етапів, сучасні методи фокусуються на тому, щоб створювати мале та вирощувати його до великого. Давайте коротко визначимо терміни:
- CI: Continuous Integration (Безперервна інтеграція)
Процес, за якого розробники часто зливають свої зміни коду в спільний репозиторій, що запускає автоматичні збірки та виконання тестів.
- CD: Continuous Delivery & Deployment (Безперервна доставка та розгортання)
Практика автоматизації коду, протестованого в CI, щоб він був готовий до ручного випуску в продакшн у будь-який час, або автоматизація самого розгортання в продакшн.
Простіше кажучи, це метод покрокового завершення проєкту з одночасною перевіркою інтерфейсу та функціональності. Раніше ці методи називали гнучкою розробкою (Agile) або DevOps (Development + Operations), але сьогоднішній підхід здається ще швидшим. Він ідеально підходить для ШІ.
В еру ШІ слід знати ще одну важливу концепцію: GitOps.
<Що таке GitOps?>
Це методологія розробки, зосереджена навколо репозиторію Git. Це концепція управління всіма визначеннями інфраструктури, конфігураціями додатків та розгортанням коду на серверах так, щоб вони повністю версіонувалися, дозволяючи відкати та ведення повної історії аудиту. Центрування всієї інформації про проєкт навколо цього єдиного джерела істини значно підвищує ефективність розробки, відмовостійкість та час швидкого відновлення.
Одно попередження щодо GitHub в епоху ШІ: як пояснювалося раніше, персональні інструменти ШІ використовують історії розмов для навчання. Конфіденційну інформацію (паролі, токени доступу тощо) необхідно захищати за допомогою GitHub Secrets. Крім того, для операцій з GitHub найкраще авторизуватися заздалегідь за допомогою GitHub CLI, перш ніж делегувати завдання ШІ.
Поганий приклад:
$ git clone https://{username}:{Token}@github.com/{UserID}/{repository_name}.git
Хоча GitHub дозволяє цей формат, він повністю розкриває ваш токен. Ви повинні завжди виконувати `gh auth login` заздалегідь, щоб вам не доводилося передавати облікові дані безпосередньо в команди Git. Інакше токен реєструється у віддаленому URL, залишаючи його видимим для всіх, тому не думайте, що це безпечно лише тому, що людина спочатку запустила команду.
Оскільки численні веб-сайти пояснюють, як створювати облікові записи GitHub та виконувати команди clone, я пропущу ці деталі тут. По-перше, ваш репозиторій (набір файлів проєкту) успішно створено.