Как стать DevOps инженером за полгода или даже быстрее. Часть 3. Версии

[Alexei_987]

Ваша картинка для привлечения внимания показывает излишне усложненную схему разработки. Использование такой схемы в 90% случаев приводит к проблемам и ошибкам. Поэтому рекомендовать ее для прод использования или ставить как КДПВ имхо не стоит.

[Makc_K]

Думаю, если бы автор объяснил приведённый на КДПВ GitFlow, то статья была бы полезной, а не просто набором общих фраз.

[Throwable]

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

[Alexei_987]

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

[Makc_K]

Проблема статьи в том, что вообще никакой подход не описан. Автор отделался набором слабосвязанных с текстом картинок и общими ничего не значащими фразами.
Коментатора заминусили за фразу:

Самый лучший способ разработки — линейный, без веток

Это не верное заявление в корне. Это заявление означает, что даже для сложного проекта, над которым работает несколько команд по нескольким направлениям надо вести линейный GitFlow без веток, хотфиксов и т.д.
Самый лучший GitFlow — тот который подходит в каждом конкретном случае.

[Throwable]

Это заявление означает, что даже для сложного проекта, над которым работает несколько команд по нескольким направлениям надо вести линейный

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

[Makc_K]

Хоть убейте. Я не вижу, чтобы автор хоть что-то предлагал. Он разместил первый найденный в интернете рисунок на тему и НИКАК его не объяснил.

Если есть возможность делать проще, нужно делать проще.

Надо делать не «проще», а так, как подходит к команде и процессу разработки. Даже если всего два разработчика, но каждый из них делает совершенно несвязанные модули одной системы, то имеет смысл вести ветку мастер и 2 ветки по одной на разработчика, чтобы по окончании условного спринта слить наработки в мастер.
А если появляется желание поэкспериментировать с какой-то новой фичей, но нет уверенности, что оно пойдёт в прод. Как вы себе это представляете без нового бранча?

[ALexhha]

Если вы представитель старой школы, то наверняка назовете свой первый файл awesome_code.p1.

я как представитель старой школы назвал бы, например, как серийник зоны в DNS Bind — YYYYmmddnn, 2020051101/2020051102

[vitraymulerman]

стать DevOps инженером за полгода

вот же дурь — даже на швею в пту 4 года учиться…

[Ryav]

задействуйте два аккаунта для хранения и демонстрации всего, чему вы научились
получите от этого выгоду!

Объясните, зачем 2 аккаунта, если можно иметь публичные (для демонстрации) и приватные (для хранения) репозитории?

[feelan]

Потому что есть люди как я, из Крыма. А у нас, как известно убрали доступ к приватным репам. Вот и приходится выживать.
habr.com/ru/news/t/461415