Огляд Dataverse інтеграції з Git (попередній перегляд)

[Ця стаття стосується попередньої версії, і її буде змінено.]

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

У цій статті ви знайдете деякі з ключових концепцій та переваг використання контролю коду з підтримкою 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, рішення, що зберігаються в контролі джерел, надходять з некерованих рішень у середовищі мейкера. Некеровані рішення дають змогу виробникам додавати, видаляти й оновлювати компоненти, синхронізовані з керуванням джерелами, коли ви вносите зміни до них і надсилаєте їх. Керовані рішення створюються на основі контролю вихідного коду та розгортаються в наступних середовищах, таких як тестові або виробничі, і в цих середовищах їх не можна редагувати. Керовані рішення використовуються для того, щоб гарантувати, що джерелом достовірності для ваших рішень завжди є контроль джерел, і що зміни вносяться лише в середовищі виробника, перш ніж вони будуть додані до контролю версій і розгорнуті в іншому місці.

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

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

Розробка на основі коду за допомогою 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 плагіни та користувацькі дії робочого процесу, є прикладами компонентів, орієнтованих на код, якими можна керувати за допомогою контролю версій.

Компоненти, орієнтовані на код і low-code в одному середовищі

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

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

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

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

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