підключаємо Git і зберігаємо історію змін
У версії платформи «1С: Підприємство 8.3.8» з'явилася можливість вивантажувати зовнішні обробки і звіти у вигляді набору XML-файлів . Ця функціональність призначена для системи 1С: EDT, але може бути використана для вирішення будь-яких інших завдань.
З її допомогою можна налаштувати Версіонування зовнішніх обробок і вирішити багато складності , пов'язані зі зберіганням і порівнянням різних версій * .epf-файлів, відстеженням змін.
Про що ця стаття
У цій статті ми:
- Розглянемо процедуру вивантаження зовнішніх обробок в XML-файли
- Підключимо систему управління версіями Git
- Навчимося версіоніровать зовнішні обробки і переглядати історію їх зміни.
Складнощі при роботі з зовнішніми обробками
Зовнішні обробки - це обробки, які не включені до складу конфігурації і зберігаються у вигляді файлів з розширенням * .epf.
Під зовнішні обробки зазвичай виносять програмний код, який не прив'язаний прямо до конкретного прикладного рішення або вимагає багаторазового запуску та налагодження.
Версіонування обробок, що входять до складу прикладного рішення, реалізується за допомогою стандартного сховища платформи, але він не дозволяє працювати з зовнішніми файлами. І в ситуації, коли обробка неодноразово змінюється і інтенсивно використовується в роботі, можуть виникнути складності:
- Не ясно, що змінилося в порівнянні з минулою версією;
- Не зрозуміло, коли саме були виконані зміни. Це можна дізнатися тільки з коментарів, якщо вони є;
- Немає можливості швидко повернутися на минулу версію обробки, якщо вона не була завбачливо скопійована і не збережена з іншою назвою або в іншій папці;
- Після деякого часу складно розібратися серед безлічі однотипних файлів.
- Щоб безповоротно не втратити змінну логіку, доводиться залишати великі ділянки закоментувавши коду (хоча коментарі повинні тільки пояснювати роботу програмного коду );
Частково складнощів можна уникнути, якщо включати обробки до складу конфігурації або розширення, підключених до сховища (підключення розширення до сховища можливо в версії платформи 8.3.12 і старше).
При цьому обробка перестає бути «зовнішньої» і втрачає одну зі своїх головних переваг: зручність швидкого доопрацювання і налагодження. Але навіть в цьому випадку порівняння версій відбувається досить повільно через особливості внутрішньої структури сховища. Детальніше про його роботу можна прочитати в статті Важливі питання про сховище .
Вивантаження зовнішніх звітів і обробок в XML
Починаючи з версії 8.3.8, платформа навчилася вивантажувати зовнішні звіти та обробки в файли формату XML, простіше кажучи - конвертувати файли * .epf і * .erf в набір файлів XML і BSL.
У вигляді XML-файлів вивантажуються форми і опис обробки, а розширення BSL використовується для файлів з вихідним текстом модулів.
Малюнок 1. Конвертація файлів
При такої конвертації на диск зберігається наступний набір файлів:
- Файл із описом обробки або звіту в форматі XML.
- Файли з описом всіх форм обробки в форматі XML.
- Файли з вихідним кодом модуля форми і модуля обробки або звіту у вигляді BSL-файлів.
З файлами такого формату можуть працювати всі існуючі системи контролю версій.
Використовуємо систему контролю версій
Система контролю версій - це програма, яка вміє зберігати безліч різних версій файлів, порівнювати їх між собою, перемикатися між версіями, відкочувати зміни, об'єднувати ці версії і багато іншого.
Такі системи розраховані на роботу з файлами у вигляді вихідного програмного коду і сприймають файли платформи 1С з розширеннями * .epf і * .erf як виконавчі, тобто просто як набір нулів і одиниць і тому не вміють їх переводити в «читається» формат.
Малюнок 2. Так бачить файл з розширенням * .epf стороння програма
Існує безліч різних систем контролю версій, а однією з найпоширеніших є Git.
Система Git використовується як інструмент версіонірованія і групової розробки в середовищі EDT (докладніше про це було описано в статті Системи контролю версій в EDT ), тому саме вона буде розглянута нижче.
Приступаємо до налаштування
Для того, щоб налаштувати Версіонування файлів обробки, нам знадобляться такі інструменти:
- Git - програма для роботи з системою управління версіями
- SourceTree - візуальний клієнт для роботи з Git
- Araxis Merge - програма для порівняння і об'єднання програмного коду.
Малюнок 3. Необхідні програми
Вибір саме цих програмних рішень не є принциповим - в якості візуального клієнта можна використовувати іншу програму, наприклад GitHub Desktop або TortoiseGit, а Araxis Merge можна замінити програмами KDiff3, WinMerge або будь-який інший. Мета даної статті - продемонструвати підхід до версіонірованія файлів платформи «1С: Підприємство», а не показати готове рішення.
Для демонстраційного прикладу буде використана зовнішня обробка «ЗагрузкаСпеціфікаціі.epf», розташована в папці «c: \ Обробки \». У папці «c: \ Repo1C \» буде створений проект Git, в якому буде зберігатися історія розробки.
Малюнок 4. Вихідний набір файлів
Інтерактивна вивантаження
Щоб вивантажити обробку в XML вручну, потрібно виконати наступні дії:
- Відкрити обробку в конфігураторі платформи версії 8.3.8 і старше
- Відкрити контекстне меню обробки
- Вибрати пункт «вивантажити в файли» і вказати потрібну папку.
Малюнок 5. Інтерактивна вивантаження обробки
Після вивантаження в обраній папці можна побачити вивантажені файли: опис обробки, форми і текст модуля форми.
Малюнок 6. Вивантажені файли
Недолік ручного способу полягає в тому, що потрібно виконувати багато дій - відкривати основну форму обробки, відкривати меню, вибирати папку. Якщо обробок буде кілька, процедура вивантаження і зовсім може затягнутися.
Процес вивантаження обробки можна автоматизувати. Для цього потрібно запустити конфігуратор в пакетному режимі.
пакетний режим
Пакетний режим передбачає виконання дій без участі користувача, при цьому конфигуратор запускається з командного рядка із зазначенням спеціальних параметрів.
Щоб зробити вивантаження обробок, потрібно запустити виконуваний файл 1cv8.exe із зазначенням ключа DumpExternalDataProcessorOrReportToFiles .
Після цього ключа потрібно вказати наступні параметри:
- Повний шлях до файлу обробки ( «що вивантажити»)
- Шлях до папки, в яку будуть вивантажені xml-файли ( «куди вивантажити»)
- Формат вивантаження: ієрархічний або лінійний. При ієрархічному форматі файли будуть вивантажені з урахуванням структури елементів, при лінійному - простим списком, при цьому тексти модулів будуть збережені з розширенням * .txt.
Виконувати такий запуск потрібно з командного консолі Windows. Щоб запустити командну консоль, потрібно відкрити меню «Пуск - Виконати» (або натиснути клавіші Win + R), написати «cmd» і натиснути Enter.
Відкриється командний рядок, в якій потрібно написати наступну команду (шлях до виконуваного файлу 1cv8.exe може бути іншим, залежно від встановленої версії платформи):
"C: \ Program Files \ 1cv8 \ 8.3.12.1529 \ bin \ 1cv8.exe" DESIGNER / DumpExternalDataProcessorOrReportToFiles "c: \ Repo1C" "c: \ Обробки \ ЗагрузкаСпеціфікацій.epf" / Out "c: \ Repo1C \ out.txt"
Малюнок 7. Командний рядок
Після виконання зазначеної команди в папку "C: \ Repo1C» будуть вивантажені файли, а в файлі out.txt з'явиться такий запис:
Малюнок 8. Вивантаження пройшла успішно
Щоб кожен раз не відкривати командний рядок і не набирати команду вручну, можна зберегти команди вивантаження в командний файл.
командний файл
Командний файл - це текстовий файл з розширенням «* .bat», який містить послідовність команд для виконання в системі Microsoft Windows.
Щоб створити такий файл, потрібно відкрити Блокнот (або будь-який інший текстовий редактор: Notepad ++, AkelPad), скопіювати в нього наступний текст і зберегти з розширенням «.bat»:
SET PATH1C = "c: \ Program Files \ 1cv8 \ 8.3.12.1529 \ bin \ 1cv8.exe"
SET EXT = "c: \ Обробки \ ЗагрузкаСпеціфікаціі.epf"
SET SRC = "c: \ Repo1C"
SET OUT = "c: \ Repo1C \ out.txt "
% PATH1C% DESIGNER / DumpExternalDataProcessorOrReportToFiles% SRC%% EXT% / Out% OUT%
SET EXT = "c: \ Обробки \ ЗагрузкаСпеціфікаціі.epf"
SET SRC = "c: \ Repo1C"
SET OUT = "c: \ Repo1C \ out.txt "
% PATH1C% DESIGNER / DumpExternalDataProcessorOrReportToFiles% SRC%% EXT% / Out% OUT%
Через особливості роботи командного процесора в назві обробки бажано не використовувати пробіли. Також може виявитися, що при запуску bat-файлу невірно розпізнається кодування. В цьому випадку потрібно перезберегти файл в OEM-866.
Малюнок 9. Збереження файлу в кодуванні OEM-866
Після того як вивантаження файлів налаштована, можна приступити до установки Git і створення сховища.
створення сховища
Для початку роботи з системою Git, слід завантажити з офіційного сайту дистрибутив програми і встановити її на комп'ютер. При установці можна залишити значення всіх параметрів за замовчуванням.
Щоб Git міг відстежувати зміни файлів в певній папці, потрібно вказати що ця папка є репозиторієм . Git фіксує зміни всіх файлів, які знаходяться в репозиторії (якщо спеціально й вказати зворотне).
Наш тестовий репозиторій буде розміщуватися в папці, в яку ми вивантажуємо обробку - «c: \ Repo1C».
Створити репозиторій можна через командну консоль, але простіше скористатися програмою SourceTree - її також необхідно завантажити з офіційного сайту і встановити. При установці потрібно вказати адресу електронної пошти (або обліковий запис Google) і пройти процедуру реєстрації. Для створення сховища потрібно натиснути на кнопку «Create» в головній панелі SourceTree і вказати повний шлях до папки:
Малюнок 10. Створення сховища в SourceTree
Після створення сховища в папці з'являється прихована директорія «.git» - наявність її означає, що Git тепер відстежує зміни файлів в цій папці.
Оскільки в папці з: \ Repo1C вже перебували вивантажені файли, Git відразу ж запропонує зафіксувати їх в сховище.
Щоб зміни файлів потрапили в сховище, файли потрібно проіндексувати - вказати, що зміни дійсно повинні бути включені в новий «знімок стану».
Малюнок 11. Приміщення змінених файлів в індекс
Для фіксування змін потрібно натиснути кнопку «Закоммітіть» (або поєднання клавіш Shift + Ctrl + C). Команда commit (з англ. - «здійснювати, фіксувати») поміщає зміни файлів в службове сховище системи Git. Аналогічною дією в сховище 1С є команда «Помістити в сховище».
Малюнок 12. Після заповнення коментаря потрібно натиснути на кнопку "Закоммітіть"
Спробуємо тепер поміняти щось в нашій обробці і перевигрузіть файли.
Наприклад, після додавання в форму процедури ПроверітьНастройкіВТабліцеДанних () ,
Git знову відобразить інформацію про те, що відбулися зміни, і в цей раз покаже, які саме частини програмного коду були змінені.
Малюнок 13. Git відображає зміни файлів обробки
Щоб не робити Комміт вручну, можна додати команди збереження змін в наш командний файл:
cd% SRC%
set / P txtcommit = "Введіть текст коментаря:"
git add.
git commit -m "% date%% time%:% txtcommit%"
set / P txtcommit = "Введіть текст коментаря:"
git add.
git commit -m "% date%% time%:% txtcommit%"
Дивимося історію змін
За допомогою програми SourceTree можна побачити історію змін файлу. Також можна «відкотитися» на потрібну версію файлів обробки. Для цього потрібно двічі натиснути на потрібному рядку в журналі змін, після чого файли в папці будуть замінені на ті, які перебували в ній до обраного коммітов.
Щоб подивитися історію змін конкретного файлу, потрібно позиційований на нього і відкрити меню «Журнал для обраного»:
Малюнок 14. Перегляд змін конкретного файлу
Для порівняння версій файлів між собою будемо використовувати зовнішню утиліту порівняння Araxis Merge .
Попередньо потрібно налаштувати SourceTree - вказати, що саме Araxis потрібно використовувати в якості зовнішнього кошти порівняння.
Малюнок 15. Налаштування зовнішньої утиліти порівняння
Малюнок 16. Щоб порівняти версії, потрібно вибрати «Зовнішня утиліта порівняння»
У вікні програми Araxis Merge можна побачити наочне порівняння версій модуля форми.
Малюнок 17. Araxis Compare порівнює версії файлу
На зображенні видно, що Araxis показав зміни в файлах і допоміг дізнатися, що саме відбувалося з програмним модулем. Наприклад, видно, що в останній версії модуля процедура ДобавітьКолонку () перейменована в ДобавітьКолонкуПоТіпу () , а також вилучені два блоки коду. Якщо в момент використання обробки виникли помилки, то переглядаючи по кроках історію доопрацювання, можна виявити момент, коли вони були зроблені.
Допрацьовуємо командний файл
Якщо удосконалити наш командний файл і додати в нього обхід всіх файлів у вибраній папці, то не доведеться створювати його копію для кожної обробки. Досить буде вказати в налаштуваннях (змінна EXT_FOLDER ) потрібну директорію, і все обробки і звіти з неї будуть вивантажені в наш репозиторій і розміщені по окремим каталогам. При цьому в лог-файл out.txt буде збережена інформація про результати вивантаження всіх файлів.
Остаточний варіант bat-файлу буде виглядати так:
SET PATH1C = "c: \ Program Files \ 1cv8 \ 8.3.12.1529 \ bin \ 1cv8.exe"
SET EXT_FOLDER = "c: \ Обробки"
SET SRC = "c: \ Repo1C"
SET OUT = "c: \ Repo1C \ out .txt "
cd / D% EXT%
del / f / q% OUT%
FOR %% F IN (* .epf * .erf) DO (
% PATH1C% DESIGNER / DumpExternalDataProcessorOrReportToFiles% SRC% %% F / OUT% OUT% - NoTruncate
)
set / P txtcommit = "Введіть текст коментаря:"
git add.
git commit -m "% date%% time%:% txtcommit%"
SET EXT_FOLDER = "c: \ Обробки"
SET SRC = "c: \ Repo1C"
SET OUT = "c: \ Repo1C \ out .txt "
cd / D% EXT%
del / f / q% OUT%
FOR %% F IN (* .epf * .erf) DO (
% PATH1C% DESIGNER / DumpExternalDataProcessorOrReportToFiles% SRC% %% F / OUT% OUT% - NoTruncate
)
set / P txtcommit = "Введіть текст коментаря:"
git add.
git commit -m "% date%% time%:% txtcommit%"
У запропонованому прикладі текст коммітов вводиться один раз для всіх обробок, але можна перенести команди системи Git в цикл FOR і вводити опис для кожного файлу.
Підведемо підсумки. Тепер ми можемо:
- Фіксувати нові версії обробки в сховище системи контролю версій. Наприклад, це можна робити в кінці робочого дня або перед початком роботи над новим блоком програмного коду.
- Переглядати історію версій і внесені зміни, щоб швидко зрозуміти, коли і що було додано, змінено або видалено.
- Порівнювати версії обробки між собою. Наприклад, можна побачити, чим саме відрізняється версія тижневої давності від поточної. Або в який момент був невірно обраний алгоритм для вирішення завдання - і при необхідності повернутися у вихідну точку.
При наявності зручних інструментів такі питання вирішуються швидше і ефективніше.
висновок
Ми розглянули основи роботи з Git і загальний спосіб версіонірованія зовнішніх обробок, який полягає в наступному:
- Обробку потрібно вивантажити в форматі * .xml.
- Вивантажені файли повинні бути поміщені в репозиторій системи контролю версій.
- Порівняння версій виконується зовнішніми інструментами порівняння.
Платформа 1С також надає можливість зворотного завантаження - формування зовнішньої обробки звіту з набору XML-файлів. Для цього існує команда «Завантажити з файлів» і ключ LoadExternalDataProcessorOrReportFromFiles .
Також за рамками статті залишилися інші можливості, які надає система Git: хмарне зберігання сховища, спільна робота над проектом і багато іншого. Вони теж можуть використані при роботі з зовнішніми файлами системи «1С: Підприємство».
Коментарі
Дописати коментар