3-я улица Строителей

[zHz00]

Когда программа пишется и функционирует на одном и том же компьютере -- это замечательно. Но могут быть и случаи, когда средства разработки стоят на одном компе, а фактическая работа происходит на другом. Это означает, что мне постоянно надо обновлять ПО на целевом компьютере и не запутаться в версиях.

У нас проекты не очень большие -- для обновления достаточно заменить пару файлов. Я, естественно, это дело автоматизировал, сделав два бат-файла -- у себя на компе и на целевом. Первый заливает нужные файлы в расшаренную сетевую папку, а второй скачивает их из папки и размещает по адресу.

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

Потом оказалось, что надо обновлять файлы ещё для одного проекта. Я стал искать, куда компилятор складывает выходной файл, нашёл, добавил в список обновления. Запускаю обновление -- показывает правильное время. Запускаю -- а правки не применяются. Присмотрелся -- время-то правильное, а дата не та. Дата двухмесячной давности! Короче, я копировал файлы из папки, предназначенной для другой конфигурации. А время случайно совпало.

Comments

[korrshun]

считай md5sum и сравнивай автоматически =)

[korrshun]

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

[zHz00]

korrshun,
>>монотонно растущего номера

Хочу посмотреть на человека, который то увеличивает, то уменьшает номер билда!

А есть инструкция как ввести нумерацию билдов?

[korrshun]

zHz00, а кто как хочет, тот так и делает.
На нынешней работе я как ответственный за релизы стараюсь следовать semver.
для ночных билдов в конец дописываю дату-время, имя ветки и кусочек хеша коммита из git. т.е. получается что-то в духе 2.3.0-202101031450-remove-orders-df234a в принципе это удобно. для релизных билдов остаётся только 2.4.0. Потом эта строчка улетают в куда-то в результирующий html или могут быть отданы через API (в зависимости от того, какой компонент я собрал - UI или бекенд).
Году в 2012м на той моей работе был SVN и там в Delphi в настройках проекта хранилась версия и прямо в IDE можно было поставить галочку "Добавлять к билду номер ревизии из SVN", он добавлялся последней цифрой к версии. Это не спасало от того, что там были локальные изменения - и это было плохо, т.к. у тебя могло быть несколько разных бинарников с одинаковой ревизией. Но это поддерживалось и в ключах компилятора, так что в один прекрасный момент мы наколхозили недоCI - собирали по кнопке на отдельной машине консольным компилятором чистый код из репозитория и релизили уже его.

[zHz00]

korrshun, вот как раз и выходит, когда мелкие правки делаешь -- не жмёшь коммит каждый раз. Ты в процессе работы. При таком подходе получается что номер билда будет всё время одинаковый? Я думал есть какой-то трюк для сквозной нумерации попыток компиляции лол.

[korrshun]

А как ты сделаешь монотонный счётчик для всей команды?
Можно брать монотонный счётчик процессора, но он слетит при выключении. В общем всё ненадёжно.
Можно конечно брать unixtime, но это будет работать ровно до того момента, пока ты не вздумаешь с локальной датой поиграться.
Разве что при билде брать время с проверенного ntp-сервера Но это тоже ненадёжно, потому что а вдруг человек на соседней машине запустит со своим набором правок в тот же момент времени? Дальше начинается ад матана с векторными часами для всех разработчиков с синхронизацией на каждом сохранении файла. Ой, это же так похоже на контроль версий! Т.е. проще выкладывать только закоммиченное, собранное в единой точке.

У меня в последние годы вебчик, и с ним всё просто - если дебажится всё локально, там нумеровать ничего не нужно. И перед коммитом делается небольшой прогон простых автотестов, для уверенности, что я ничего фатально не разломал.
На тестинг это всё попадает уже через CI, и там нужные и правильные ID билдов возникают сами по себе.
И да, я в своей ветке коммичусь часто и довольно мелкими кусками - так на самом деле проще, в коммит-месседже можно высрать небольшой дамп мозга с предпосылками и это потом поможет, когда через полгода будешь разгребать по git blame а какого лешего так. И мелким коммитам гораздо проще делать git revert, чем большим.
А когда я вижу коммит хотя бы на 200 строк да ещё и с невнятным мессаджем - мне хочется откатить его на месте, а потом взять канделябр и прибить того, кто так делает. Потому что в этой каше не разобраться.

В принципе можно аналогично жить и в твоём случае - наколбасить автобилды и наливку на целевую машину прямо из репозитория и коммитить часто. Просто жуткая боль, когда ты изменения внёс, собрал-залил бинарник, а потом случайно что-то нажал/ушёл на обед/пришёл на следующее утро и изменения просрались. И вроде бы всё работает, но надо заново писать и отлаживать. Это бывает редко, но очень неприятно. Ещё CI немного помогает и отрезвляет от ситуаций, когда у разных людей по-разному настроено IDE. Из-за подобной херни у меня на той работе с SVN система у двух разработчиков собиралась и работала нормально, а у третьего - вроде бы тоже, но крашилась потом в рантайме на специфичных кейсах. Т.к. зависимостей много, настройки компиляции сложные, никто не мог долго понять, а что случилось (подсказка - порядок библиотек при линковке). На чистой машине для CI мы это один раз ключи компилятора настроили, скрипт написали и забыли об этой проблеме. И код брался всегда чистый, без кеша - от этого мы тоже странности с регулярно имели, когда собирали боевой билд на девелоперских машинах, дельфи иногда считал, что не надо перекомпилировать файл, хотя на самом деле надо, т.к. где-то там менялась структура данных в зависимостях.

Если потом очень захочется, то можно через git rebase переписать историю и сделать красиво, но вот ни разу не хотелось, правда.