×Закрыть

Сеньоры и лиды, которые боятся коммитить в VCS

Коллеги.
Столкнулся с проблемой, что некоторые seniors и даже lead engineers отказываются коммитить в svn, т.к. «это может всё поломать», «я не уверен в коде», «мне нужно время поэкспериментировать на кошках» и т.п..
Что посоветуете делать?

👍НравитсяПонравилось0
В избранноеВ избранном0
LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Установить CI сервер и написать много интеграционных тестов.

Только Git спасет их от боязни

Скорее всего их уже ничего не спасет.... ))

Кстати заюзать гит наскоком, непрочитав что оно такое и как им пользоватся — очень здорово отвернет желание пользоватся любыми вцс вооще :-)

Для начала нужно правильнее формулировать проблему. Уверен, что те, кто отказывается, мыслят (по своему) рационально. Видимо есть нечто, что не очевидно.
Например, у нас типичная причина отказа что-то коммитить это:
— любой день 18:00 (так как после коммита нужно дождаться выполнения ВСЕХ тестов это +1час и если что-то пойдет не так — то к полуночи уйдешь домой). Кроме того, работающие с нами люди в другом часовом поясе будут ну очень рады увидеть красный билд утром (в наше время это 4 утра).
— любой день — человек не прогнал у себя на машине все необходимые тесты. Хуже, когда публика «посмелее» коммитит без прогона тестов и потом никто костей собрать не может.

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

Кстати, упоминалось, что они ждут апрува от QA — есть причины? QA по поводу этого что говорит? Нет Application-Level тестов или достаточного покрытия тестами дабы быть уверенным в чем то?

Я говорб о том, что сорцы подправляются прямо на серваке.
Собирается билд.
Он уходит в QA.
В случае проблем — они правятся снова.
Таким образом нормально понять что было изменено в последнем билде — невозможно.
Изменения в бранче.

Я говорб о том, что сорцы подправляются прямо на серваке.
Повторюсь:
Что за ЦИ? Большинство делает чекаут сами.

TeamCity.
Повторяю ответ. Clean checkout не делается т.к. долго, делается простой апдейт.
Перед апдейтом правятся сорцы.

Повторяю ответ. Clean checkout не делается т.к. долго, делается простой апдейт.

confluence.jetbrains.net/.../Clean Checkout

TeamCity tries to detect if the sources in the checkout directory are not corresponding to the expected state and triggers clean checkout in such cases to ensure sources are appropriate.

То есть если:

Перед апдейтом правятся сорцы.

То при апдейте изменения потрутся. Я когда настраивал первый его раз, сдуру, правил скрипты прямо на сервере и они перезаписывались теми что были в СВН.

Внезапно.
" Clean checkout не делается.Так как долго, делается простой апдейт."

Внезапно.

" Clean checkout не делается.Так как долго, делается простой апдейт.«

Куда кликать?
Смотрю на «Configuration Steps»
Выбрал «Version Control Settings»
Что там выбирать?
Есть «Clean all files before build:». Если ее выставить то сначала удалит все файлы, потом выкачает.
Если ее не ставить, то перезатирает локальные файлы теми что с сервера.

Куда кликнуть чтобы у локальных был приоритет?

Тяжело.
“Clean all files before build:” не ставится — т.к. долго.

«Clean all files before build:» не ставится — т.к. долго

И чекаут все равно делаетсо :)

Делается апдейт.
По стилю вы напоминаете мне коллег, уважаемый :)

Делается апдейт.

Ну вам виднее.

делать ноги. может быть там вирус рака мозга.

Так а проблемма то в чем???
Вам нужен срочно их неотлаженный код?
Вы хотите помочь в отладке?

Если это не его личный (под фичу/баг/etc) бранч — то правильно человек делает.

съесть еще этих мягких французских булок

и выпить чаю

повна версія:
“Съешь еще этих аццких олбанских креведок, да выпей йаду”

У нас есть отдельная ветка для каждого программиста для экспериментального кода, откуда код уже можно потом перенести в рабочий.

Собственно гиг места на сервере стоит менее часа разработчика.

Говорить. Общаться с людьми. Почему ты думаешь что нужно коммитить, а они — нет. Может вы о разных вещах говорите. Неплохо бы получше топики формулировать, а то что-то получилось типа «кажется у меня в программе баг — что делать?»

Извиняюсь за оффтоп, но аватарка у ТС и наличие значка того, что аккаунт подтвержден, как бе намекает нам о том, какая полезность от этого подтверждения :)

какая полезность от этого подтверждения :)

Ну может он кореш сами знаете кого ;)

ДОУ следует ИТ-моде: все по аджайлу.

Это не проипали это аджайл! ©

я бы таких сеньоров и лидов даже в пшп не взял бы :)

слова интеграционный сервер, pre-tested-commit, TeamCity им ни о чём не говорит? Если не секрет, в какой же конторе работают подобные чудо-разработчики?

в каком центре? я в люксофте работал лет 5 и во всех проектах у нас использовались интеграционные сервера. Правда вместо тим-сити юзали круиз-контроль.
а еще в Люксофте был 23-летний архитектор и тимлид :-)

Гнать таких оленей взашей, неча подавать дурной пример подрастающему поколению и сеять страх в стройных рядах жителей стойла опенспейса!

а ЗП они получать не боятся?

Всё просто. Они просто целый день нихрена не делали, откладывали на потом, чтоб за пол часа накидать кучу кода и закоммитить, но не успели, т.к. были дела поинтереснее, а про боюсь это сказки на отъе..сь

мы с вами не на одном проекте работаем?

ващето есть trunk/stable стратегия для свн
мержить из trunk в stable могут даже qa, после тестов.

в сложных случаях можно делать «трехуровневую» систему — trunk — для разработчиков, stable_inner — для qa, stable — продакшн

Они вообще с опытом работы или их просто так сеньорами набрали, когда 23-летние уже закончились?

Может вы их там бьете, после неудачных камитов, вот и боятся.

В принципе, и правильно делают, что боятся. Решение — организация бранчей. %IMHO%

А у вас есть куда еще коммитить, кроме основной ветки? :) Может я чего не понял. Создаете отдельный бранч под какую-то не совсем мелкую задачу. Ну и пусть туда коммитят, тестируют. Затем мерджите этот бранч в основную ветку. Причем, мерджить изменения может совсем другой человек, даже лучше.

а за что тогда получают зп?

Есть хорошая книга — Continuous delivery. там четко написано как организовать процесс так, чтобы не возникало таких страхов и рисков. Основное правило такое — непроверенный, неработающий

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

это решается простой вещью. Демы не на чем кроме серверов которые берут код с пайплайна не делать. Эти поделки просто теряют смысл.

У себя на рабочей станции хоть обдрочись.

А по-русски можно?
Пайплайны, демы...

попробую тяжело о работе на русском просто. Пайплайном для проектов назвают ситуацию когда все что демонстрируется\считается рабочим попадает на демо сервер только по одному пути отревьювили- закомитили-сбилдили континуус интегрейшен системой-ей же потестили юнит интегрейшен и фанкшинал тесты- ей же развернули систему на демо сервере. Т.е хождение на деплой сервер руками и что то там шаманить — нештатная ситуация или чп.

да. А в чем проблема то?

еще забыл сказать что и билд и тест серверов много и выполение кластеризировано. В Bamboo например или hudson все замечательно настраивается.

Пусть отдел тестирования делает регрессию на тестовых серверах близких к боевым и развеивает страхи и неуверенность сеньоров и лидов:)

Что посоветуете делать?

Писать тесты, БЛ...!!1АДЫН
Настроить ЦИ, БЛ...!!1АДЫН

Разделить стабильную ветку и девелопмент. Но тут уже сложнее чем «одной кнопкой».

И что дадут тесты, если они правят прямо на CI-сервере сорцы?
«Clean checkout перед каждым билдом — это долго, а еще наши изменения потеряются»

И что дадут тесты, если они правят прямо на CI-сервере сорцы?
Чееее?
«Clean checkout перед каждым билдом — это долго, а еще наши изменения потеряются»
При 1,7 Гб сорцев, оверхед максимум 5 минут (полный билд 40-50 мин)

Вот именно, что правят на серваке.

ох это как то так круто что я в это практически не верю. Круче только по фтп на продакшене править. Или тоже высоко котируете данный способ? :P

Я за VCS. Но ребята умудряются комментить несобирающийся код в 3rd-party библиотеках, а потом с круглыми глазами спрашивать «А что мне было делать? Надо же было собрать быстро.»

Меняю свой ответ

Что посоветуете делать?

Валитенахоттуда!

«А что мне было делать? Надо же было собрать быстро.»

Это же очевидно: если закомментил код, для того чтобы собрать и все таки собралось — закоммить изменение. Меняешь на билд-сервере — коммить с билд-сервера, создавай баг мол «фигня эта ваша заливная рыба, пришлось выкинуть, чините».

Оно собралось. Но в результате того, что 3rd-party не собирается/тестируется после каждого билда — во время работы начались проблемы.
Дядя просто создавал новую конфигурацию и ему было лень грамотно собрать и запустить тесты для сторонней либы.
Он зарепортил, что всё ок и выдал продукт.

Он зарепортил, что всё ок и выдал продукт.

тогда только массовые расстрелы для спасения демократии

Вот именно, что правят на серваке.

Это как? Нормальные ЦИ сами делают чекаут, даже если что-то поменять, то оно затрется. Что это у вас за чудо такое?

Кстати, сталкивался с подобной ситуацией, когда требовалось за 1 коммит (и вообще без коммита) получить полнстью рабочую программу. При этом, разумеется, результат (патч) можно было получить только после 10-20 прогонов сборки на CI.

И чё? Начнём спор о крутизне git?
Вопрос не в том куда коммитить.
Они не коммитят никуда, в принципе.
«Пока stable не будет.» т.к. «чуют нештат».

Комитить нужно после каждого маленького шага рефакторинга, даже банального переименования переменной.
После того как закончил функционал отсылаешь все комиты в центральный репозиторий.
SVN делать локлальные комиты не позволяет в принципе, нужен DVCS.
Самый популярный DVCS это git.
Если ваш проект ещё не на DVCS значит у вас некомпетентные сотрудники.
Но можно партизанить — Git может работать с SVN репозиторием.
Вариант рабочий и проверенный годами.

Если ваши 23хлетние тимлиды и синьёры ещё не сделали этого тогда гнать их в шею, мы не в Индии.

>Если ваш проект ещё не на DVCS значит у вас некомпетентные сотрудники.

А вот и срачик начинается.

> SVN делать локлальные комиты не позволяет в принципе

SVN позволяет делать бранч. Недостаток в том, что все увидят метания 23х летнего тимлида.

Недостаток в том, что все увидят метания 23х летнего тимлида.

это уже психиатрическая проблема :) часто сопряжено с уверенностью что все что закомиченно — высечено в мраморе и неумением пользоваться VCS as is: код добавляют, и скачивают изменения других разработчиков, но не умеют откатывать, не понимают что VCS можно и нужно использовать для сохранения своих же промежуточных результатов. и пофигу svn там или git: в git будут коммитить точно так же.

У нас такое было с народом который пришел из других команд, где подобная практика принята, и соответственно svn, в наш git. На какое-то время помог разговор с аргументом: «если я не вижу ваших коммитов, я делаю вывод что задача не сделана, а вы не работаете, а страдаете фигней», и в качестве продолжения «вы пл$ть разработчики или куда. IDE/редактор и VCS — это инструменты которыми вы обязаны владеть, и использовать», плюс небольшая иллюстрация того что я ожидаю видеть в VCS, вместо монументальных творений. До кого-то почти дошло с первого раза, кто-то переспрашивает перед каждым коммитом «мне это коммитить?», но дело слегка сдвинулось с мертвой точки.

«Раньше вы жили не так, теперь мы будем жить по другому» — прокатит увы не для всех. Нужно медленно, но упорно толкать людей в нужном направлении, ну или менять людей. Могут помочь штуки типа peepcode, они в Play by Play уделяют время VCS и тому как опытные разработчики VCS пользуются: посмотришь, может и себе «бест практику» утащишь.

можно жить с тем же SmartGit и не замечать что остальные живут в SVN

я с svn работаю через git-svn
в гите есть такая няшка — stash — т.е. коммит, но локальный (особенно удобно переключатся если вдруг срочно чет другое надо исправить а у тебя тут ползадачи только сделано)

Интересно в git stash list через полгода посмотреть. Такие интересные вещи можно найти...

ну если не «чистить» то да :)

может, все же stage? stash — это нечто вроде буфферной зоны, куда вообще с любой бранчи можно кидать и в любую бран восстанавливать.

не. я именно про stash , stage немного не о том.

если бы еще git-svn мержить умел в svn :(

Отказываются так как умны:) Это признак некоторого опыта и вдумчивости как минимум. Не боятся только те кто ничего не понимают.

Точняк.
Т.е. теперь не коммитить — это модно? Пусть всё лежит локально и при каких-то проблемах потратим день на ручной revert?

Бранчи надо делать, или юзать вообще распределенную систему контроля версий типа гита или меркуриала, и держать у себя локально репозиторий. Коммитить неработающий или подозрительный код в основной бранч недопустимо.

Я говорю про основной бранч и правки прямо на серваке.
После правок прогоняются тесты, но они тоже не коммитятся — страшно.

На revert чего? О чем вообще ты говоришь? Какая разница когда код будет закомичен, за час или за два. А если три человека лезут в один и тот же код, то во-первых договариваться нужно, во-вторых это не revert, а мержд ручной, а в-третьих, кто последний комитает — его проблемы (если уж не можете договориться).
И вообще, это его код — когда допишет — тогда закомитает, какое тебе дело до этого? У тебя своих тасков нету?

Что посоветуете делать?

Скажіть, що завжди є можливість відкату із поломаних версій до робочих, і ще можна постійно робити бек-ап робочої локальної версії (якщо вже їм так страшно).

Самое интересное, что они делают локальные модификации прямо на билд-сервере.
Но не коммитят, «пока не будет аппрува от QA, что версия стабильна».

Може їх десь сильно в дитинстві били за поламані коміти?
А там як процес поставлений?
Може ліпше комітим скільки влізе в робочий бренч (транк), і заодно робиться якийсь окремий бренч, де заморожується стабільна версія для проміжного релізу.
Звичайно має бути людина, яка тримає під контрполем цей процес і тримає живими робочі версії

Это в Люксофте такие специалисты работают?

Якщо так — мінус 5 в карму люксофту :)

Пока будет аппрув от QA — кто-то другой успеет накоммитить много раз, возможно затронув используемые классы, в итоге «правильный» коммит всё-таки сломает билд.
Возможно так же, что у вас всего пара-тройка разработчиков на проекте и они все тайно используют локальный git/hg/etc репозиторий вместо нелюбимого svn :)

Пока будет аппрув от QA — кто-то другой успеет накоммитить много раз, возможно затронув используемые классы, в итоге «правильный» коммит всё-таки сломает билд.

Бардак на корабле.

Причем тут тогда коммиты в svn, если нарушен весь процесс?
Если человек не коммитает изменения локальные — то это его дело.
А если он лезет в обход svn — то это уже нарушенный процесс или его отсутствие, а не боязнь чего-то.

Подписаться на комментарии