Огляд інтеграції Git в Power Platform

Інтеграція контролю версій дозволяє командам розробників синхронізувати рішення та об’єкти рішень в одному або кількох Microsoft Dataverse середовищах за допомогою Azure DevOps репозиторію Git. Функція інтеграції контролю вихідного коду доступна в межах можливостей рішень, що гарантує, що громадянські розробники, розробники коду та адміністратори можуть отримати вигоду від контролю версій, відстеження змін та безперебійної співпраці команди в різних інструментах і середовищах. Інтеграція Git призначена для використання з середовищами розробника, а не з вашими тестовими або продакшн-середовищами, де розгортання може бути виконано за допомогою збірок для створення артефактів рішень і конвеєрів для Power Platform розгортання.

У цій статті ви знайдете деякі з ключових концепцій та переваг використання контролю коду з підтримкою Git у ваших Dataverse середовищах та рішеннях. Щоб отримати інформацію про Git in Azure DevOps, перейдіть до Azure DevOps репозиторію Git.

ALM в Power Platform і Dataverse

Power Platform надає багато готових можливостей, які дозволяють організаціям керувати керуванням життєвим циклом програм (ALM) для своїх рішень. Включена можливість упаковувати рішення як контейнери для безлічі різних типів об’єктів на платформі, керувати середовищами, що беруть участь у життєвому циклі програми, і розгортати рішення за допомогою пайплайнів в. Power Platform Існує також кілька способів інтеграції репозиторіїв Git за Power Platform допомогою інструментів розробника. Завдяки вбудованій інтеграції Git Dataverse, процес спрощується та спрощується для того, щоб виробники могли працювати зі своїми рішеннями звичним способом та взаємодіяти з керуванням вихідним кодом за допомогою спрощених інтерфейсів in Power Apps (make.powerapps.com).

Пільги

• Контроль джерел як джерело правди: У деяких організаціях джерелом правди для розгортання є Dataverse середовища виробників, в яких будуються рішення. Основною рушійною силою такої поведінки є те, що нерідна інтеграція Git використовує передові методи та інструменти, які вимагають професійних ІТ-знань для початку. Завдяки вбудованій інтеграції Git in Dataverse, контроль коду може бути включений всього за кілька кроків і надає знайомий інтерфейс для роботи виробників зі своїми рішеннями.
• Безпека, аудит і відповідність вимогам з використанням найкращих практик SDLC: найкращі практики життєвого циклу розробки програмного забезпечення (SDLC) — це набір інструкцій і процесів, які допомагають ефективно керувати проектами з розробки програмного забезпечення. Використовуючи інтеграцію Dataverse Git, ви дотримуєтеся практик SDLC, таких як контроль версій, рев’ю коду та статичний аналіз вихідного коду, щоб забезпечити якість, надійність та безпеку ваших рішень. Інтеграція Dataverse Git також надає такі функції, як аудит, відповідність та відстеження, які допомагають вам відстежувати зміни у ваших рішеннях та ефективно співпрацювати з іншими членами команди.
• Недовговічні середовища розробки: Зберігаючи копію налаштувань та конфігурацій ваших середовищ у системі керування версіями, ви можете швидко та легко Dataverse відновити рівень розробки з контролю вихідного коду. Це дозволяє створювати короткочасні середовища для цілей розробки та тестування. Короткочасні середовища дозволяють вам звільняти сховище, експериментувати з новими функціями, тестувати та ітерувати свої рішення, не покладаючись на постійні середовища.
• Команди розробників Fusion: Команди розробників Fusion – це команди, які складаються як з розробників, так і з мейкерів, які працюють разом над створенням рішень. Використовуючи інтеграцію Dataverse Git, ці користувачі можуть самостійно створювати в окремих середовищах та співпрацювати з іншими, синхронізуючись із загальним репозиторієм контролю коду. Інтеграція контролю версій дозволяє використовувати навички та досвід як розробників, так і виробників для створення високоякісних рішень, які відповідають потребам вашої організації.
• Захист: використання контролю джерел як джерела достовірної інформації для ваших рішень дозволяє вам швидко та легко відновлюватися після небажаних змін у ваших рішеннях. Зберігаючи свої рішення в системі керування версіями, ви можете відновити їх до попереднього стану або версії.

Основні поняття

Некеровані та некеровані рішення

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

Форматування файлів для об’єктів рішення

З впровадженням інтеграції Git відбулися Dataverse зміни у способі представлення рішень та об’єктів рішень у контролі джерельних кодів. Коли ви комітуєте та вносите зміни до контролю джерела, об’єкти рішення зберігаються у спеціальному форматі, сумісному з Git. Цей формат використовується для представлення об’єктів рішення таким чином, щоб його було легко прочитати та зрозуміти, а також можна використовувати для відстеження змін в об’єктах рішення з часом. Формат файлу для об’єктів рішення розроблений таким чином, щоб бути зрозумілим людиною і може використовуватися для перегляду змін в об’єктах рішення в системі керування вихідним кодом. Крім того, щоб дозволити зберігати кілька рішень в одному репозиторії та папці, об’єкти рішення в Source Control більше не дублюються для кожного рішення. Натомість, об’єкти рішення зберігаються в одному місці та можуть бути спільними для кількох рішень в одному репозиторії та папці.

Розробка на основі коду за допомогою Git

Розробка на основі першого коду в Power Platform можлива за допомогою інструментів розробки, таких як Power Platform розширення CLI Visual Studio та Visual Studio Code. Залучення розробників, орієнтованих на код, у процес розробки рішень є складним без інтеграції контролю джерела, оскільки такі об’єкти, як Power Apps елементи керування фреймворком компонентів та Dataverse плагіни, розгортаються в рішеннях як упаковані активи, створені з вихідного коду та не доступні для безпосереднього редагування ( Power Apps make.powerapps.com). Без контролю вихідного коду як частини процесу розробки як low-code, так і code-first об’єктів, важко керувати змінами в рішенні та гарантувати, що зміни відстежуються та розгортаються контрольованим чином.

Увімкнувши інтеграцію Dataverse Git, ви можете зустрітися з розробниками, які орієнтуються на код, там, де вони працюють, і забезпечити безперебійну роботу як для low-code, так і для розробників, які працюють з першим кодом. Однак є деякі міркування, які слід мати на увазі при управлінні об’єктами, орієнтованими на код, у середовищі з низьким кодом.

Розробка Fusion з Dataverse інтеграцією з Git

Power Platform Надає можливості як для low-code, так і для code-first. У цій статті обговорюються процеси розробки, пов’язані з Dataverse інтеграцією Git, і надаються рекомендації щодо управління об’єктами з першим кодом і низьким кодом в одному середовищі. Такі об’єкти, як Power Apps елементи керування компонентними фреймворками, Dataverse плагіни та користувацькі дії робочого процесу, є прикладами об’єктів, орієнтованих на код, якими можна керувати за допомогою контролю джерела.

Об’єкти з першим і низьким кодом в одному середовищі

Об’єкти, орієнтовані на код, можуть бути включені в рішення за допомогою процесу збірки, який генерує кероване або некероване рішення, яке можна імпортувати в Dataverse середовище. Однак об’єкти, орієнтовані на код, також можуть бути розгорнуті безпосередньо в некероване рішення в середовищі maker після того, як вони були створені, без використання процесу збірки рішення для їх розгортання. Є процес складання, який слід враховувати, враховуючи цю гнучкість.

Якщо ви розгортаєте об’єкти, орієнтовані на перший код, безпосередньо в некерованому рішенні в середовищі виробника, коли ці об’єкти передаються контролю джерела, у службі контролю версій зберігаються лише їхні скомпільовані (побудовані) версії. Наприклад, двійковий DLL, якщо плагін, або транспіляризований і оптимізований пакет JavaScript для контролю фреймворку компонентів Power Apps . У результаті ви отримуєте дві копії об’єкта в елементі керування версіями — одна представлена зібраною версією, а інша — вихідним кодом. Зберігання двійкових файлів у вашому репозиторії може призвести до плутанини та потенційних конфліктів, якщо вихідний код і побудована версія не синхронізуються. Така практика не рекомендується, оскільки вихідний код має бути єдиним джерелом достовірності для об’єкта, а зберігати слід лише одну копію.

Рекомендований підхід полягає в тому, щоб створювати об’єкти, орієнтовані на код, як частину процесу збірки рішення, та імпортувати згенероване некероване рішення в середовище мейкера. Цей підхід гарантує, що вихідний код і побудована версія синхронізуються, а вихідний код є єдиним джерелом правди для об’єкта. Однак цей підхід вимагає, щоб у вас був процес збірки для створення керованого або некерованого рішення для використання в процесі імпорту та розгортання. Ви можете створювати, наприклад, робочі процеси Azure Pipelines або GitHub, які створюють артефакти для конвеєрів у Power Platform процесах синхронізації Git та для використання.

Наступні кроки

Dataverse Налаштування інтеграції з Git