Выкатка в прод немного отличается. Алгоритм следующий: 1. Lock master branch 2. Rebase on origin/master 3. Deploy to production 4. Track metrics 5. Merge to master 6. Unlock master
Если на 4-м шаге возникли какие-то проблемы то просто откатываем на последний мастер. Разработчик полностью отвечает за весь цикл разработки фичи и сам катит ее в прод. Каждая фича катится атомарно, то есть нет необходимости выяснять кто и что сломал в ветке где идет интеграция при подготовке релиза, так как "релизов" по сути нет. При таком флоу нормальная продуктивная команда из 5-7 человек катит в прод 2-3 раза в день.
Мы же особенности flow обсуждаем, причем тут джуны и ошибки?
Как раз с точки зрения риска и сложности gitflow проигрывает, если мы говорим о типичной backend разработке.
Зачем рисковать возникновением эмерджентных багов при интеграции фич , усложнять цикл разработки и размывать ответственность введением таких ролей как релиз-инженер и тд, когда можно быстро катить фичи атомарно?
Научить людей ребейзить - не очень сложная задача.
При чем тут конфликты? Если мы ребейзнули ветку на последний мастер, то мерж этой ветки в мастер будет fast-forward, master и feature-branch будут указателями на один и тот же коммит.
Снепшот кода который мы деплоим будет одинаковым в обоих вариантах флоу:
# flow 1
git fetch
git rebase origin/master
deploy to prod
git checkout master
git merge feature-branch
# flow 2
git fetch
git rebase origin/master
git checkout master
git merge feature-branch
deploy to prod
Понятно что в реальности есть куча нюансов, если команда большая, то возможно будет нужно настроить merge queue и тд., но думаю, общий смысл понятен.
"звучит неправильно" - так себе аргумент. Код в ветке после ребейза на мастер ничем не отличается от кода в мастере после мержа. Разница между этими подходами только в том, что сливая в мастер до выкатки мы увеличиваем вероятность получить сломанный коммит в мастере.
GitFlow имеет смысл только если нет простого механизма отката изменений из прода (читай "мобильная разработка"). В остальных случаях GitHub Flow проще и стабильнее. Для обеспечения стабильности, катить в прод нужно до того как слили в мастер, и сливать только после того как убедились, что ничто не сломано. Если сломано - rollback на последний мастер в общем случае.
Разумно предположить, что доступ к объекту obj[key] займет O(1), но на деле это определяется многими факторами — размером объекта, частотой создания / удаления etc...
Не вижу причин не поговорить на собеседовании о производительности и ее связи с асимптотическим анализом сложности. Например из этого рассуждения я бы сделал вывод что кандидат знаком с самой идеей, нотацией и некоторыми классическими структурами данных, но не очень понимает идею амортизированной трудоемкости. В принципе, позволяет сделать какие-то выводы об уровне кандидата. Что плохого в таких вопросах?
In the present case of 2019-nCoV, virus isolates or samples from infected patients have so far not become available to the international public health community. We report here on the establishment and validation of a diagnostic workflow for 2019-nCoV screening and specific confirmation, designed in absence of available virus isolates or original patient specimens. Design and validation were enabled by the close genetic relatedness to the 2003 SARS-CoV, and aided by the use of synthetic nucleic acid technology.
Но забавно, что автор этого не заметил. Кажется, он материалы по собственным ссылкам не читал :)
на вопрос назовите что последнее вас удивило отвечает «в канаде сделали робота доилку»… фейспалм.jpg
Отличный ответ! Последнее, что меня, например, удивило — это то, что у самки кенгуру 3 влагалища. Кстати, чем опытнее человек, тем сложнее его удивить, как правило.
Я в этой ветке оставил ровно один коментарий (помимо этого), ничего про «голый доцкер» не писал. Ответил на ваш «HA в 5 строк конфига». Так-то, в «днищенских конторах которым на одного средненького одмина денег жалко» и HA нафиг не уперся. А все эти рассуждения про 5 строчек и про то, что «VK и FB вон вообще на PHP пишут» говорят о том, что вы, скорее всего, большие проекты только на картинках видели.
В общем и целом - https://githubflow.github.io/
Выкатка в прод немного отличается. Алгоритм следующий:
1. Lock master branch
2. Rebase on origin/master
3. Deploy to production
4. Track metrics
5. Merge to master
6. Unlock master
Если на 4-м шаге возникли какие-то проблемы то просто откатываем на последний мастер.
Разработчик полностью отвечает за весь цикл разработки фичи и сам катит ее в прод. Каждая фича катится атомарно, то есть нет необходимости выяснять кто и что сломал в ветке где идет интеграция при подготовке релиза, так как "релизов" по сути нет. При таком флоу нормальная продуктивная команда из 5-7 человек катит в прод 2-3 раза в день.
Мы же особенности flow обсуждаем, причем тут джуны и ошибки?
Как раз с точки зрения риска и сложности gitflow проигрывает, если мы говорим о типичной backend разработке.
Зачем рисковать возникновением эмерджентных багов при интеграции фич , усложнять цикл разработки и размывать ответственность введением таких ролей как релиз-инженер и тд, когда можно быстро катить фичи атомарно?
Научить людей ребейзить - не очень сложная задача.
При чем тут конфликты? Если мы ребейзнули ветку на последний мастер, то мерж этой ветки в мастер будет fast-forward, master и feature-branch будут указателями на один и тот же коммит.
Снепшот кода который мы деплоим будет одинаковым в обоих вариантах флоу:
Понятно что в реальности есть куча нюансов, если команда большая, то возможно будет нужно настроить merge queue и тд., но думаю, общий смысл понятен.
Расскажите это ребятам из google или yandex :)
"звучит неправильно" - так себе аргумент. Код в ветке после ребейза на мастер ничем не отличается от кода в мастере после мержа. Разница между этими подходами только в том, что сливая в мастер до выкатки мы увеличиваем вероятность получить сломанный коммит в мастере.
GitFlow имеет смысл только если нет простого механизма отката изменений из прода (читай "мобильная разработка"). В остальных случаях GitHub Flow проще и стабильнее. Для обеспечения стабильности, катить в прод нужно до того как слили в мастер, и сливать только после того как убедились, что ничто не сломано. Если сломано - rollback на последний мастер в общем случае.
Может, если задачи несложные.
Не вижу причин не поговорить на собеседовании о производительности и ее связи с асимптотическим анализом сложности. Например из этого рассуждения я бы сделал вывод что кандидат знаком с самой идеей, нотацией и некоторыми классическими структурами данных, но не очень понимает идею амортизированной трудоемкости. В принципе, позволяет сделать какие-то выводы об уровне кандидата. Что плохого в таких вопросах?
Спасибо, ребята. Вы делаете очень крутые инструменты!
> Стоит отметить, что цикл событий встроен в Go
Что вы имеете в виду?
Но забавно, что автор этого не заметил. Кажется, он материалы по собственным ссылкам не читал :)
Но некоторые сделают из увиденного абсолютно неверные выводы :)
Вот мой linked-in если что www.linkedin.com/in/david-klassen
Естественно, страница ничего не ищет, ищет бэкенд, а страница батчами подгружает то что бэкенд нашел.
Отличный ответ! Последнее, что меня, например, удивило — это то, что у самки кенгуру 3 влагалища. Кстати, чем опытнее человек, тем сложнее его удивить, как правило.
Я в этой ветке оставил ровно один коментарий (помимо этого), ничего про «голый доцкер» не писал. Ответил на ваш «HA в 5 строк конфига». Так-то, в «днищенских конторах которым на одного средненького одмина денег жалко» и HA нафиг не уперся. А все эти рассуждения про 5 строчек и про то, что «VK и FB вон вообще на PHP пишут» говорят о том, что вы, скорее всего, большие проекты только на картинках видели.