Я просто свято верю в то, что чем меньше кода ты написал - тем лучше, а так же заставляю себя и окружающих не забывать, что каждая написанная строка кастома увеличивает затраты на поддержку всего решения. Об этом часто забывают. А потом ищут отдельного человека, который способен поддерживать получившегося монстра, я такое не раз видел:)
Я кстати в одном месте пробовал как ты, в другом - подвинул эту логику внутрь самого пайплайна, то есть там по сути подпрограмма с минимумом использования самого гитлаба. В принципе, второй вариант в итоге мне больше понравился)
да вот чет жирно получается, например мы активно используем там сервисы, и джоба тестов перед стартом запускает dind, redis, postgres & rabbitmq свои
Я просто свято верю в то, что чем меньше кода ты написал - тем лучше, а так же заставляю себя и окружающих не забывать, что каждая написанная строка кастома увеличивает затраты на поддержку всего решения. Об этом часто забывают. А потом ищут отдельного человека, который способен поддерживать получившегося монстра, я такое не раз видел:)
донести никак, к этому сами приходят. но очень помогает sonar с жесткими quality gate и отдельный dev productivity дэшборд который у всех на виду: trend line LoC, CI build time trends, test coverage, smells, days till next release и open issues. в какой-то момент разработчики начинают видеть связи
Я просто свято верю в то, что чем меньше кода ты написал - тем лучше, а так же заставляю себя и окружающих не забывать, что каждая написанная строка кастома увеличивает затраты на поддержку всего решения. Об этом часто забывают. А потом ищут отдельного человека, который способен поддерживать получившегося монстра, я такое не раз видел:)
Но вообще ты идеалист конечно. Твои методы классные, но всегда надо иметь в виду правило 0 - они действуют только на хороших специалистов, которые от них становятся еще лучше.