Jump to content

    

Версия ПО+ GIT

Добрый день, на писал на C# скрипт который от текущее время преобразует строку, и записываем массивом в файл, а этот файл подцепляю к проекту, и из массива вывожу на дисплей. Потом по дате можно поискать в логах GIT и найти комитет(нужный исходник), но это как-то не очень, было бы круче если тэг текушей ветки сразу бы заносился в массив, ну или что нибудь из GIT что бы можно было быстро и легко найти исходник(версию), зашитой программы.

Что можно в GIT использовать в качестве идентификатора?

Хотел ТЭГ, но

1) не нашел как узнать тэг текущей ветки

2) его надо в ручную инкрементировать =(

Share this post


Link to post
Share on other sites

0xFF:

После того, как по сгенерированному файлу собрана версия, какая она будет после её занесения в систему контроля версий?

Share this post


Link to post
Share on other sites

Можно завести отдельный фал, в котором лежит версия проекта. И написать два хука:

.git/hooks/pre-commit в котором автоматически перед коммитом делается инкремент версии в этом файле и делается git add этого фала

.git/hooks/post-commit в котором автоматически после коммита делается чтение этой версии и она записывается в тег через git tag -a

 

Share this post


Link to post
Share on other sites
Можно завести..

 

+5 копеек

- добавить вэб морду для гита

- из CI системы можно сделать выбор необходимой версии и сборку в ручном режиме (автомат при этом так-же работает от пуша)

- ссылки из системы тасков в гит с записью в комментарии сообщения из коммитов (кто, что, референс в гит, версия, репозиторий и т.п.)

 

и т.д..

 

(круглый)

 

Share this post


Link to post
Share on other sites

arhiv6, благодарю, надо будет разобраться в хуках.

kolobok0, Спасибо за CI, не знал что есть такое, какая самая простая?

Edited by pokk

Share this post


Link to post
Share on other sites
...Спасибо за CI, не знал что есть такое, какая самая простая?

 

тут на цвет и вкус.

но лично сам больше сталкиваюсь с Jenkins

более-менее устойчив, сообщество, достаточно большой выбор плагинов, куча опыта по юзанью в инете.

 

И ышо

5 копеек

Если вектор разработки в сторону вэбовских дел, то рекомендую глянуть технологии микросервисов, docker-container ну и управлялку под эти дела - rancher.

Последний так-же рулится из джэнкинса. Так-же из джэнкинса можно собирать контейнеры, регистрировать их (как пример) в локальном реестре и оттуда грузиться либо на рабочие станции либо в rancher.

 

 

с уважением

(круглый)

ЗЫ

Теоретически в контейнеры можно загонять усё чё не лень(тот же самый Jenkins). Но бОльший профит можно ожидать только от микросервисной технологии.

Edited by kolobok0

Share this post


Link to post
Share on other sites

Наконец то появилось время что бы продолжить сборку проекта, расписал все что хотелось бы видеть в сборке получилось вот что:

  1. Включалась сборка HTML страницы (GULP)
  2. Включалась утилита конвертации страницы в массив  (.exe)
  3. создавалась версия ПО (инкремент+ HSA1 комита)
  4. компиляция hex файл
  5. Копирование полученный файл в папку HEX с новым именем версии ПО
  6. Соединение  Hex файл c Hex файлом BootloAder
  7. Создание временного файла hex файл с добавления серийного номера

Половину уже сделал на скриптах python, только встал вопрос как это все запускать ?  Сейчас пока сделал  что большая часть запускается при Merge в релизную версию. Но кажется мне такой подход не совсем корректным. 

Как это все сконфигурировать нормально ? В одних проекта некоторые шаги не нужны,в других нужны.  И как это сделать универсально что бы легко можно было перенести в новый проект. 

 

Share this post


Link to post
Share on other sites
On 6/18/2019 at 7:37 AM, pokk said:

...на скриптах python, ...как это все запускать ? ...при Merge в релизную..Как ..сконфигурировать нормально ? ...как .сделать универсально ..перенести в новый проект. 

 

Тут ещё пол копейки.
Есть подход гитлаба (халява при поднятии своего, для мелких проектов - самое то) ну или заюзать вэб сервис от поставщика.
Так вот гитлаб может отрабатывать pipeline скрипт которых настраивается как yaml файл лежащий прямо в репе (или даже группа файлов). При этом перенос очень прост - меняется именно этот файл при переносе в другую репу.
Пайпа отрабатывается в ранерах гитлаба. По уму это разные тачки и ранеров может быть много. В пайпе можно делать параллельные и последовательные зависимости, ловить разные глаголы(не только мёрдж реквест), есть связи с мессэнджэрами, почтой, различными зоопарками. Немного глючноват, но терпимо.
На пайпах можно вызывать отработку любых докер контейнеров. А что внутри них вы отрабатываете - фигня вопрос. Хоть баши, хоть питоны, хоть пых-пыхи и т.д. и т.п..

Можно собирать артифакты которые легко переносятся между ранерами автоматом (один билдовка например, а второй крутиться на таргет машине. направили на развёртывание в таргет машину - тут же раскатали в продакшен)...

как то так
(круглый)
ЗЫ
Гит флоу вытекает из ворк-флоу. Обычно на бранчах работа быстрая, без изменений исходников. Например простановка тэгов. Причём имя генерируется с указанием имени бранча и уникального счётчика(привет кастом атрибутам). Выставляем тэг. На данный тэг можно ссылаться внешней автоматикой для дальнейшей сборки-CI. На мёрдже реквесте(точнее при его подготовке) идёт проверка исходников = билдовка, прогон тестов, наращивание версии (если пушим в мастер или релиз), коммит изменений, выставление тэга.
Можно прерывать пайпу и выходить на дальнейшее ручное проталкивание. Либо от настроек на проекте выставленные внешней автоматикой мы идём по нужным настройкам - например собирать ли, куда выкладывать, куда раскатывать и т.д. и т.п...

Edited by kolobok0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now