Тему снесли в архив CI-CD интересен ли опыт?

Довёл дело до статьи — получилось описание всего пути: как перевели систему с 7-ки на 8.3 и заодно построили вокруг неё DevOps (GitLab, Jenkins, тесты, CI/CD). Статья на Хабре: https://habr.com/ru/articles/1080264

Скрипты пайплайнов  в приложении в конце статьи.

По статье видны промахи в части анализа работы пользователей и их потребностей. Плохо что 77 разработчика не привлекли к работе над переходом, стопудово он кучу всего знал, а в результате пришлось асфальт закатывать повторно.
.
Технически, наверное, интересно. Но результат неясен. Во что обходилась поддержка старой системы, во что обходится новая.
.
Теперь понятно почему лет 7 назад хороший имплант у хорошего спеца было поставить было ощутимо дешевле... ;-)

В начале статьи упоминалось что решили писать свое. Потом всплыла адаптация решения какого о чьи исполнители в результате слились. Кто-то халатно из заказчиков отнесся к выбору

Если будет риск, что я зависну в пустыне, возьму эту статью с собой. Воды хватит надолго.

(0) Вы действительно не знаете как посмотреть конкретную строку модуля без турбоконф?

Код на скринах это как не нужно писать код. Аж глаза закровоточили.

(0) > 80-100 активных пользователей

> Релизы делаем 4 раза в неделю

нах...я так часто?

хотя... ERP щас тоже раз в неделю рылиз выкатывают в час по чайной ложке (раз в неделю)

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

(7) в пределе несколько раз в день. Непрерывный поток изменений. Как в Лед и Пламя у Бредбери.
Некогда остановиться.

(7) (8) Не понимаю. Какой профит? Тестирование как? На пользователях?

(9) Тестирование в идеале сразу в процессе разработки и автоматизировано с актуализацией, но в 1с чаще всего да на юзерах)

(8) Serios Bussines

(4) Знаю конечно. Но суть в другом, при общении и разборе кода удобнее и быстрее назвать строку которая сразу видна, через переходить через ctrl+G
6) небольшие изменения проще в отслеживании и отладке. Задачи находится в фокусе как у разработчика, так и у заказчика.

Простой в опте или бухгалтерии вполне поправим и можно сместить по времени. Документ проведёшь позже, отгрузку сдвинешь на час.
В медицине по-другому. В этот момент есть живой пациент - он на приёме, в очереди на анализ или ждёт результат для лечения. Самое главное, человек болен, его сознание изменено. Нельзя сравнить психическое состояние здорового индивида и человека с недугом. Для больного здоровье первоочередное. Ну представь ты себе больной зуб, а в регистратуре тебе скажут, у нас база не работает, ждём 15 минут.
Задержка приема на 5-10 минут чревата негативом для всех, в том числе и разработчиков. Не работает касса - нельзя оформить приём. Не открывается карта - врач не видит историю болезни. Встала лаборатория - нет результата. Поэтому управление риском в работе ПО выходит на первый план. Все изменения должны быть проверены, оттестированы и необходима уверенность, что новая фича не ломает старую логику.

(12) Успеваете тесты писать быстрее чем код? Или по принципу - чтобы старое не сломалось?

(13) практически все тесты написаны после ошибок, косяков и тд.
Вот сделал новую фичу, и в случае поломки чего-то другого и замечания по системе, будь добр, напиши новые тесты.
Из нас, никто их не любит писать. Даже так, это воспринимается как наказание.

За пару лет набралось суммарно примерно 100 штук сценарных тестов. Это покрывает блоки критичные к работе.

(14) А, понятно. Классика.

(0) В целом все эти CI/CD  мне не особо нравится, потому что это очень часто съедает кучу ресурсов, а выхлоп около нулевой.
Если у вас большой проект где работает допустим более 10 разработчиков, и чтобы все это организовать такие системы могут дать какой то выхлоп.

Но когда у вас 1 разработчик и вместо того, чтобы нанять еще одного и увеличить выхлоп от работы грубо говоря в 2 раза , ресурсы вместо этого тратится на это - мне кажется того не стоит. На таких небольших проектах как по мне это все не нужно и не эффективно

(16) По моим скромным оценкам, выхлоп должен получиться когда разработчиков больше 4, и хотя бы один аналитик и один тестировщик. И эта команда только на разработке, без поддержки.
Но х.з. Может кто-то умудряется все, сразу, и везде.

(17) у нас меньше людей, но плюсы для есть.
Во-первых, я решал свои задачи при помощи Ci-CD. Хотел сделать систему устойчивой и катить изменения быстрее.

Во-вторых, ставить релиз самому в тех.окно ночью или просить кого-то - это ужас. Ночью нужно спать, а днём бодрым и отдохнувшим я работаю.

В-третьих, настройка и поддержка заняли немного времени. Дольше искал оптимальный вариант, чем настраивал.

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

(18) Ни в коем случае не умаляю ваш результат. Очень полезно и интересно.
Аналитика пишущего тесты еще могу представить, а вот программиста - х.з. Он же созидатель. ИИ может покрыть весь код тестами, но вряд ли он поймет смысл покрытия. Хотя х.з.

Сценарии для тестов пишем сами, через обработку vdrunner не ИИ. А так, смотрим-наблюдаем за тем, как реально работает пользователь. Целые  рабочие сценарии.

Я поделился своим опытом, так как даже в сложных условиях возможно облегчить себе жизнь доступными инструментами.