Как релизится GitHub

Для end-to-end тестов инфраструктура чуть ли не важнее самих тестов. Это для Unit-тестов соотношение Code LOC/Test Loc может быть меньше 1, а для end-to-end этот показатель обычно больше 100. Но вот написать его в виде автоматически выполняемого сценария очень сложно, ибо много инфраструктурных вещей надо сделать: базы поднять, настройки развернуть, запросы нужные сделать, данные базы посмотреть. Готового Фреймворка для этого нет.

Здорово было бы, но ИИ пока не изобрели,… а если бы изобрели он бы и основной код писать смог )

Ага, причем если время близится к обеду/концу рабочего дня, проверяет «зеленые» билды диффами. Если удаленных строк больше, чем добавленных, пишет «Are you kidding me?» и не открывает двери)

Судя по скриншоту — у них флаги под каждый отдельный feature-brunch. А флаги/branch`и можно и удалять по истечению определенного срока (к примеру когда фича уже стабильна ее просто добавляют в master).

я не в курсе насчет выступления, но статью прочитал взахлеб :)

Пока еще не вложили, по крайней мере я тоже не нашел. По ссылке в статье есть слайды.

С тем, что на Западе больше профессиональных разработчиков (т.е. разработчиков ориентированных на продукт) я согласен. Мне кажется, что корни этого растут еще из образовательных проектов. В тех же Штатах, насколько я слышал от знакомых, которые там учились, всё направлено на создание совместных проектов, которые, вроде как, почти всегда должны идти в мир, становиться основами для собственных стартапов и так далее. У нас же почти все студенческие проекты заранее приговорены к смерти в конце семестра. Вот и получается, что акцент на то, чтобы сдать зачет / закрыть таск.

При этом сильные компании, в которых есть культура ориентированности на продукт, собирают почти всех сильных программистов. А из таких компаний программисты скорее уезжают за рубеж, чем идут в компании поменьше. Поэтому «культура продукта» распространяется не столько личным примером, сколько статьями на Хабре и других ресурсах.

Имхо.

Тут дело в приоритетах компании.
Есть, например, такое понятие как principle of good enough, а у других — другие приоритеты.

Ну это выглядело бы глупо, если бы они не исправляли баги)
Подобный подход может работать только в случаях, когда деплой можно провести за пару минут (т.е. быстренько сварганить хот-фикс и сразу исправится ошибка) И когда пользователи лояльны (а в большинстве случаев программисты именно такие, ведь «у всех бывает» (с) ) в случае десктоп и мобильных приложений, подобный подход — сущее зло и тут не о чем спорить:)

Ну в поле ввода для текста описания ошибки сказано, что если я уложусь в 140 символов, то они подарят золотую звезду. Так кстати, до сих пор и не подарили ( Я им каждый раз напоминаю «где моя звезда, guys?»

То, что сервис меня устраивает в целом, не означает, что меня устраивает его стабильность, вроде очевидно. Стабильность гитхаба вообще мало кого устраивает, это его объективный минус, который уже стал притчей во языцех.

Bitbucket работает намного стабильнее и предсказуемее, пользуюсь обоими, поэтому могу сравнивать.
Можно ещё сравнить твиттеры:
twitter.com/bitbucket: последнее сообщение о проблемах 30 сентября;
twitter.com/githubstatus: последнее сообщение 15 часов назад.

Я не к тому, что подход гитхаба неприемлем, совсем нет, и практика это доказывает. Но то, что у них отсутствует QA, и тестируют они на пользователях, активным пользователям очевидно без всяких статей. Просто они осознанно забили на стабильность в обмен на что-то ещё, поэтому если нужен надежный сервис — их подход не вариант.