Кто должен разруливать конфликты интеграции?
Кто должен идти чинить?git
Не, не слышали 
Ну и это не волшебная же пуля, конфликты все равно будут.
Ну и это не волшебная же пуля, конфликты все равно будут.
Выделенный merge rota чувак!
кто последний тот и мерджит!
кто последний тот и мерджит!это очевидно
Это когда в один бранч, тогда очевидно. Ибо ты в принципе не можешь закомитить, пока не разрешишь конфликты.
А тут надо найти продблемный комит в прод, проблемный комит в дев, сравнить их таймстемпы. Автоматизировать все это? Или кто должен идти проблемные комиты вычленять и таймстемпы сравнивать?
А тут надо найти продблемный комит в прод, проблемный комит в дев, сравнить их таймстемпы. Автоматизировать все это? Или кто должен идти проблемные комиты вычленять и таймстемпы сравнивать?
Считай одна бранч Дев.
У вас продакшен бранч одна или на каждый релиз?
У вас продакшен бранч одна или на каждый релиз?
Вы когда в продакшн отгружаете регресс не тестите?
И нахера две ветки для одного продукта?
И нахера две ветки для одного продукта?
Кто должен разруливать конфликты интеграции?НАТО.
Мне кажется, что тот кто делает хотфикс на проде, должен его применить ко всем остальным веткам.
Эээ, а где же пчОлы?
Одна
Мне кажется это настолько единственно возможным вариантом, что я не нахожу аргументов для Кости, почему это его работа.
Нет, не тестим. И да, две ветки много, мы обычно прям из дева релизим, причем иногда из локальной сборки. Но это все отдельные вопросы.
Мне кажется это настолько единственно возможным вариантом, что я не нахожу аргументов для Кости, почему это его работа.Когда делается мердж из дев в прод? Логично это делать перед отгрузкой.
Между отгрузками комиты идут в дев. Костя делает свою таску сначала в прод. А поскольку между отгрузками комиты должны попадать в дев, то Костя для завершения своей таски должен промерджить свою таску в дев (да, возможно, ему придется разобраться в новой версии кода и сделать свою таску еще и на новой версии кода).
Сережа ничего не делал в прод, поэтому он не мерджит из прод в дев.
Мердж из дев в прод при отгрузке должен происходить без конфликтов.
В результате конфликт и автоматическая мержелка из прода в дев отваливается. Кто должен идти чинить?т.е. вопрос кто должен мерджить из прод в дев? Чьи change set-ы тот и мерджит.
Позиция Кости, что прод бранч соответствует проду, и он все пофиксил и закомитил и все работает. И он может сделать одолжение и замержить разок, но вообще дев — это помойка, которую он не трогал, и что там происходит, его не трогает.
Нет, тут был экстренный релиз, который пошел из прода сразу. То есть Костя сделал фикс на проде и зарелизил. Следующий релиз пойдет как ты пишешь: сначала мержим из дева в прод, потом релизим.
Позиция Кости, что прод бранч соответствует проду, и он все пофиксил и закомитил и все работает. И он может сделать одолжение и замержить разок, но вообще дев — это помойка, которую он не трогал, и что там происходит, его не трогает.дев - это тот код, который в один прекрасный момент превратится в продакшн код. Если Костя несет ответственность за этот кусок функциональности, то стоит пофиксать и будущий продакшн (дев а не только текущий.
Если не несет - то и фикс на продакшне уже был типа как одолжением. Тогда вполне можно поручить фикс в девелопменте ответственному. И фикс этой баги может быть другим и более тщательным, чем быстрая затычка от человека, который "к этой помойке никакого отношения не имеет".
Позиция Кости, что прод бранч соответствует проду, и он все пофиксил и закомитил и все работает. И он может сделать одолжение и замержить разок, но вообще дев — это помойка, которую он не трогал, и что там происходит, его не трогает.Костя понимает, что его комит создал проблему в будущем, когда будете мерджить из дев в прод и про его фик уже все забудут, включая его самого? Кому и как он предлагает решать эту проблему? Если его это не трогает, то его не трогает разработка продукта, который вы делаете. Если сотрудника не трогает разработка продукта, то для него могут быть серьезные последствия.
Упоротый чувак, чо.
Я бы просто ему сказал, наверное - "твой фикс, значит твои проблемы, чтобы он был во всех будущих релизах. Кто куда будет мерджить мне пох - если надо сам и договаривайся."
Я бы просто ему сказал, наверное - "твой фикс, значит твои проблемы, чтобы он был во всех будущих релизах. Кто куда будет мерджить мне пох - если надо сам и договаривайся."
если делать бранч на релиз, то проще
твой фикс, значит твои проблемыинициатива наказуема?
инициатива наказуема?почему инициатива? он же не сам решил в продакшен бранче от нехуй делать покодить.
Другое дело что все должны понимать, что на коммите в бранч работа не заканчивается, а заканчивается только после мержа фикса/создания нового фикса в транке.
он же не сам решил в продакшен бранче от нехуй делать покодить.а откуда мы знаем, как там обязанности распределены?
может костя мог просто открыть баг и ждать, но он решил уменьшить ущерб от простоя и закодил фикс сам?
уменьшить ущерб от простояв итоге может увеличить, перед релизом часто цейтнот и проблемы с мерджем совсем некстати
включаю телепатию и вижу, что костя - это кто-то вроде админа, который отвечает за то, чтоб некая продакшн-система работала без сбоев, а серёжа - девелопер, которому интересно накодить побольше клёвых фишек и поскорее зафигачить их в продакшн
тогда косте слишком тяжело разбираться в девелоперском бранче, а серёже слишком уныло портировать багфиксы
тогда косте слишком тяжело разбираться в девелоперском бранче, а серёже слишком уныло портировать багфиксы
обязанность фиксить на руководителе, который данный вопрос не регламентировал.
Почему же, все строго регламентировано, все обязанности и правила действия в различных ситуациях досконально расписаны по пунктам!
— Товарищ прапорщик, а мне мясо положено.
— Положено, так ешьте!
— Но мне его не положено!
— Ну не положено, так не ешьте!
лично моё имхо такое - если тебе дали право коммитить в vcs, то ты должен соблюдать те же правила коммита, что и остальные пользователи этой vcs. я так понимаю, что правила о мердже с костей оговорены не были, но это не отменяет того, что некие правила всегда есть.
ЗЫ: у кости хватило силы духа выкатить в продакшен фикс и быть уверенным, что это не порушит всю систему, но при этом он не может разобраться в следующей версии этого же приложения? по-моему такой ковбойский подход к разработке и поддержке ничем хорошим не заканчивается.
ЗЫ: у кости хватило силы духа выкатить в продакшен фикс и быть уверенным, что это не порушит всю систему, но при этом он не может разобраться в следующей версии этого же приложения? по-моему такой ковбойский подход к разработке и поддержке ничем хорошим не заканчивается.
Нет, все тут девелоперы.
Продлема есть уже сейчас, что мержилка сломалась и каждый день рассылает письма с просьбой ее починить. Впрочем, письма можно отправить в спам.
Продлема есть уже сейчас, что мержилка сломалась и каждый день рассылает письма с просьбой ее починить. Впрочем, письма можно отправить в спам.
У меня тоже хватает духу совать маленькие патчи в свой ebuild, чтобы заткнуть, а не решить конкретный баг. Пока не подводили.
Впрочем, письма можно отправить в спам.
На поверхности же!
Simple is better than complex.
Прикинься злым напившимся русским!
Какие будут потери от простоя, вызванного твоей самодеятельностью?
Если вы несколько дней не можете договориться, кто чинит,
то у вас проблемы, причём виноваты в них все задействованные лица.
---
"Vyroba umelych lidi, slecno, je tovarni tajemstvi."
то у вас проблемы, причём виноваты в них все задействованные лица.
---
"Vyroba umelych lidi, slecno, je tovarni tajemstvi."
Не будет самодеятельности - не будет работать софт. От слова вообще. Но тут уж кому как больше нравится. По идее такие баги просто не должны доходить до прода, но ведь доходят же.
Я же с самого начала написал - ковбойский подход к разработке ничем хорошим не заканчивается. То что такие баги доходят до продакшена - следствие подхода. Относились бы чуть ответственнее - не пришлось бы в продакшене патчи накладывать.
То есть Костя сделал фикс на проде и зарелизил.И всё-таки, какая у Кости была мотивация? Он исправил чужой баг, свой баг или Серёжин баг?
Никто не спорит, что симл проще. Все споры о том, что есть симпл. Можешь пояснить, что конкретно ты выдишь на поверхности?
Почему ж? Два дня мы просто этот вопрос не обсуждали.
Да там вообще старая компонента, которой хз кто владеет. Но по крайней мере Костя в теме ее функциональности. Чего Сереже в том коде надобно было, я вообще не в курсе.
Ну и кстати, имхо, ответ не должен зависить от мотивации.
Остальные пользователи стараются не комитить в прод, но в целом тоже делают, че хотят.
Всё зависит от того, как организована работа и что делал Костя в проде. Может быть его изменения вообще не надо графитить в дев, т.к. у него некая заплатка, которая после переделок Серёжи вообще не потребуется. Иногда в обязанностях Серёжи - вытягивать из основной ветки все изменения и их адаптировать к своему новому коду. Иногда приходится сажать обоих за один монитор, чтобы мёржили совместно. Кто последний - тот и мёржит, - это работает, когда все разработчики работают в одной ветке. Да и то иногда так выходит, что приходится мёржить парами.
делают, че хотят.в таком случае идеальный вариант - отправлять письма в спам и пусть дальше делают чо хотят.
Ну как бы автоматическая мержился из прода в дев сломалась и плачет. Можно ее, конечно, добить, но жалко. Так что нету у Сережи обязанности вытягивать ничего. Сесть вдвоем за монитор — не вопрос. Кто это должен инициировать?
Ну и кстати, имхо, ответ не должен зависить от мотивации.Почему? На моей памяти такие ситуации решались по-разному, и чаще всего решения зависели от мотивации, которая привела к исправлению бага. Если же оба упёрлись, то в дело должен вмешаться руководитель. Конечно, если у вас гугло-яндексо демократия, то этого не произойдёт, и оба будут пытаться что-то доказывать друг-другу, полностью игнорируя реальность.
> Почему ж? Два дня мы просто этот вопрос не обсуждали.
Тогда обсудите и договоритесь.
На твой вопрос есть пять разных ответов. Который из них применим,
зависит от ваших внутренних обстоятельств, установок, договорённостей.
---
"Мой диалектический метод по своей основе не только отличается
от гегелевского, но является прямой его противоположностью."
Тогда обсудите и договоритесь.
На твой вопрос есть пять разных ответов. Который из них применим,
зависит от ваших внутренних обстоятельств, установок, договорённостей.
---
"Мой диалектический метод по своей основе не только отличается
от гегелевского, но является прямой его противоположностью."
Слишком много софта так разрабатывается. Видимо, не случайно. Посмотри на багтрекеры линуксячих дистров. Частенько баги в прикладных программах фиксят мейнтенеры пакетов, накладывая на них быстропатч. И живут как-то. И мейнтенеры и разработчики софта.
будет красноглазить всю ночь и чинить гентушечку, вместо того, чтобы флудить на форуме
Если что-нибудь случилось,
И никто не виноват,
Не ходи туда, иначе
Виноватым будешь ты.
Спрячься где-нибудь в сторонке.
А потом иди домой.
И про то, что видел это,
Никому не говори.
И никто не виноват,
Не ходи туда, иначе
Виноватым будешь ты.
Спрячься где-нибудь в сторонке.
А потом иди домой.
И про то, что видел это,
Никому не говори.
Кто это должен инициировать?как выше заметил , у вас проблемы
И всё-таки, какая у Кости была мотивация? Он исправил чужой баг, свой баг или Серёжин баг?При правильном процессе разработки все баги - общие.
Вообще, нормальный работник должен делать всегда чуть больше, чем требовалось. Тогда гарантированно не будет никаких зазоров на границах разных подсистем и пр. Если бы Костя и Сережа не были долбоебами, они бы еще и поспорили за право замерджить в дев ветку.
Ну как бы автоматическая мержился из прода в дев сломалась и плачет. Можно ее, конечно, добить, но жалко. Так что нету у Сережи обязанности вытягивать ничего. Сесть вдвоем за монитор — не вопрос. Кто это должен инициировать?Так очевидно же. Никто не должен инициировать. Но если один инициировал, то он - молодец, а если никто не инициировал, то оба - лохи.
Какие будут потери от простоя, вызванного твоей самодеятельностью?Ну вот смотри, простейший пример. Наш любимый рутрекер забанил мой любимый deluge клиент. О том, что это именно делюга он узнаёт из протокола торрента. Но сама делюга не имеет опций для подмены строки клиента. Потери от простоя без фиксов - большие, всё просто не работает, торрент трекер не отдаёт информацию. А можно поковыряться в исходниках, недолго. И подменить одну-единственную строковую константу. И всё работает. Потенциально есть потери от простоя, равные изначальным, ведь клиент может сломаться после правки. Вот только если в первом случае вероятность - единица, то во втором - милионная доля. Скажешь я поступил не правильно, или такая ситуация исключительная?
Если бы Костя и Сережа не были долбоебами, они бы еще и поспорили за право замерджить в дев ветку.Устроили бы поединок, и победитель сделал бы мердж, а проигравший сэппуку.
ты изначально по-ковбойски поступил завязав свои бизнес-процессы на ресурс, на который не можешь повлиять, теперь расхлебываешь результаты своей безалаберности.
то есть, условно говоря, я должен был выбрать другой софт? А думаешь в другом софте не будет каких-нибудь других мелочей, вылазящих в самый неподходящий момент?
нет, ты должен был выбрать другой торрент-трекер.
о как. А компания соответственно должна была выбирать других клиентов? И что значит выбрать другой? Я торрент трекер не выбирал, я взял там, где было. Было бы на нормальном, взял бы на нормальном. А если есть на хреновом, значит надо уметь работать и с хреновым. Зачем добровольно урезать себе возможности?
слушай, ты вообще умеешь читать? если бы ты тебе нужен был постоянный доступ к рутрекеру, то ты бы нашел способ договориться об этом с теми, кто управляет рутрекером. но ты предпочитаешь другой подход - "помолились и в продакшен", и именно в твоем подходе кроется причина того, что тебе приходится накладывать патчи на продакшен.
слушай, ты вообще умеешь читать? если бы ты тебе нужен был постоянный доступ к рутрекеру, то ты бы нашел способ договориться об этом с теми, кто управляет рутрекером.А если мне нужен постоянный доступ ко всякому торрент трекеру, а не к одному конкретному? Ведь рутрекер тоже не полон. Что если приложение в продакшене обслуживает не одно предприятие, а тысячи разных с разными ньюансами?
тогда ты неправильно выбрал технологии, на которых строить систему, т.к. в твоем случае тебе придется под каждый торрент трекер держать deluge со своими патчами.
virtualenv - это не проблема. Мы сейчас обсуждаем другую тему: быстропатч vs глубокий фикс. Завести несколько virtualenv - это быстропатч. А добавить тычку в гуи "выбрать client_id" - это глубокий фикс. Но ты как раз посоветовал использовать быстропатч, значит признаёшь этот способ исправления багов осмысленным.
Но ты как раз посоветовал использовать быстропатч, значит признаёшь этот способ исправления багов осмысленным.щито? я вроде сказал что ты неправильно выбрал технологии, т.к. тебе придется применять много быстропатчей.
virtualenv - это не проблема. Мы сейчас обсуждаем другую тему: быстропатч vs глубокий фикс. Завести несколько virtualenv - это быстропатч. А добавить тычку в гуи "выбрать client_id" - это глубокий фикс.нет, глубокий фикс - это выкинуть все то говно, что ты уже наклепал и сделать по-нормальному, включая голову когда надо.
Оставить комментарий
Realist
Два бранча: дев и прод. Костя поправил прод пока Сережа девелопит в деве. В результате конфликт и автоматическая мержелка из прода в дев отваливается. Кто должен идти чинить?Можно голосовалочку?
[pollstart]
[polltitle=Кто должен мержить?]
[polloption=Костя]
[polloption=Сережа]
[polloption=merge rota]
[polloption=кому больше всех надо]
[pollstop]