Pull to refresh
59
0
David Klassen @f0rk

Программист

Send message

В общем и целом - 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 будут указателями на один и тот же коммит.

Снепшот кода который мы деплоим будет одинаковым в обоих вариантах флоу:

# 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 и тд., но думаю, общий смысл понятен.

Расскажите это ребятам из google или yandex :)

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

GitFlow имеет смысл только если нет простого механизма отката изменений из прода (читай "мобильная разработка"). В остальных случаях GitHub Flow проще и стабильнее. Для обеспечения стабильности, катить в прод нужно до того как слили в мастер, и сливать только после того как убедились, что ничто не сломано. Если сломано - rollback на последний мастер в общем случае.

Кандидат может не знать теорию, но справляться с задачами на должном уровне?

Может, если задачи несложные.
Разумно предположить, что доступ к объекту obj[key] займет O(1), но на деле это определяется многими факторами — размером объекта, частотой создания / удаления etc...

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

Спасибо, ребята. Вы делаете очень крутые инструменты!

> Стоит отметить, что цикл событий встроен в Go

Что вы имеете в виду?

Мм… оттуда же.
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.

Но забавно, что автор этого не заметил. Кажется, он материалы по собственным ссылкам не читал :)
Мы решили проблему балансировки keep-alive соединений в кубе не используя headless service :)
Любой может открыть в хроме инструменты разработчика и лично посмотреть чего и сколько скачивается.

Но некоторые сделают из увиденного абсолютно неверные выводы :)
Ну-ну, расскажите мне как все работает у этих :)
Вот мой linked-in если что www.linkedin.com/in/david-klassen
страница занята тем что скачивает огромный кусок, а вовсе не ищет что-то.

Естественно, страница ничего не ищет, ищет бэкенд, а страница батчами подгружает то что бэкенд нашел.
Ага, а крипту за наличные в подворотне покупать :)
В каком месте ООП ложится ровно на железо? Это же граф из каких-то хреновин выделенных на хипе, все кэш-лайны идут мимо.
на вопрос назовите что последнее вас удивило отвечает «в канаде сделали робота доилку»… фейспалм.jpg

Отличный ответ! Последнее, что меня, например, удивило — это то, что у самки кенгуру 3 влагалища. Кстати, чем опытнее человек, тем сложнее его удивить, как правило.
Начали с голого доцкера

Я в этой ветке оставил ровно один коментарий (помимо этого), ничего про «голый доцкер» не писал. Ответил на ваш «HA в 5 строк конфига». Так-то, в «днищенских конторах которым на одного средненького одмина денег жалко» и HA нафиг не уперся. А все эти рассуждения про 5 строчек и про то, что «VK и FB вон вообще на PHP пишут» говорят о том, что вы, скорее всего, большие проекты только на картинках видели.

Information

Rating
Does not participate
Location
Таиланд
Date of birth
Registered
Activity