Коллеги.
Столкнулся с проблемой, что некоторые seniors и даже lead engineers отказываются коммитить в svn, т.к. «это может всё поломать», «я не уверен в коде», «мне нужно время поэкспериментировать на кошках» и т.п..
Что посоветуете делать?
Установить CI сервер и написать много интеграционных тестов.
Скорее всего их уже ничего не спасет.... ))
Кстати заюзать гит наскоком, непрочитав что оно такое и как им пользоватся — очень здорово отвернет желание пользоватся любыми вцс вооще :-)
— транк который скоро уйдет в релиз. Любые радикальные изменения, мягко скажем, не желательны. Иногда даже некоторые баги фиксить не желательно (т.к. софтина уже протестирована, на это ушла эдак неделя и твой коммит череват перетестированием всего приложения (я имею ввиду теорему про чётное число ошибок в программе)). Вот и получается, что локально изменения есть (например, новая фича), а бранч (тег) с релизной версией еще не создали, получается и коммитить-то некуда :).
Кстати, упоминалось, что они ждут апрува от 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 не делается.Так как долго, делается простой апдейт.«
Куда кликнуть чтобы у локальных был приоритет?
Тяжело.
“Clean all files before build:” не ставится — т.к. долго.
«Clean all files before build:» не ставится — т.к. долго
И чекаут все равно делаетсо :)
Делается апдейт.
По стилю вы напоминаете мне коллег, уважаемый :)
Делается апдейт.
Ну вам виднее.
делать ноги. может быть там вирус рака мозга.
Если это не его личный (под фичу/баг/etc) бранч — то правильно человек делает.
и выпить чаю
повна версія:
“Съешь еще этих аццких олбанских креведок, да выпей йаду”
У нас есть отдельная ветка для каждого программиста для экспериментального кода, откуда код уже можно потом перенести в рабочий.
Собственно гиг места на сервере стоит менее часа разработчика.
Говорить. Общаться с людьми. Почему ты думаешь что нужно коммитить, а они — нет. Может вы о разных вещах говорите. Неплохо бы получше топики формулировать, а то что-то получилось типа «кажется у меня в программе баг — что делать?»
Извиняюсь за оффтоп, но аватарка у ТС и наличие значка того, что аккаунт подтвержден, как бе намекает нам о том, какая полезность от этого подтверждения :)
Ну может он кореш сами знаете кого ;)какая полезность от этого подтверждения :)
ДОУ следует ИТ-моде: все по аджайлу.
Это не проипали это аджайл! ©
слова интеграционный сервер, pre-tested-commit, TeamCity им ни о чём не говорит? Если не секрет, в какой же конторе работают подобные чудо-разработчики?
в каком центре? я в люксофте работал лет 5 и во всех проектах у нас использовались интеграционные сервера. Правда вместо тим-сити юзали круиз-контроль.
а еще в Люксофте был
Гнать таких оленей взашей, неча подавать дурной пример подрастающему поколению и сеять страх в стройных рядах жителей стойла опенспейса!
Всё просто. Они просто целый день нихрена не делали, откладывали на потом, чтоб за пол часа накидать кучу кода и закоммитить, но не успели, т.к. были дела поинтереснее, а про боюсь это сказки на отъе..сь
в сложных случаях можно делать «трехуровневую» систему — trunk — для разработчиков, stable_inner — для qa, stable — продакшн
Они вообще с опытом работы или их просто так сеньорами набрали, когда
Может вы их там бьете, после неудачных камитов, вот и боятся.
В принципе, и правильно делают, что боятся. Решение — организация бранчей. %IMHO%
А у вас есть куда еще коммитить, кроме основной ветки? :) Может я чего не понял. Создаете отдельный бранч под какую-то не совсем мелкую задачу. Ну и пусть туда коммитят, тестируют. Затем мерджите этот бранч в основную ветку. Причем, мерджить изменения может совсем другой человек, даже лучше.
а за что тогда получают зп?
У себя на рабочей станции хоть обдрочись.
А по-русски можно?
Пайплайны, демы...
попробую тяжело о работе на русском просто. Пайплайном для проектов назвают ситуацию когда все что демонстрируется\считается рабочим попадает на демо сервер только по одному пути отревьювили- закомитили-сбилдили континуус интегрейшен системой-ей же потестили юнит интегрейшен и фанкшинал тесты- ей же развернули систему на демо сервере. Т.е хождение на деплой сервер руками и что то там шаманить — нештатная ситуация или чп.
еще забыл сказать что и билд и тест серверов много и выполение кластеризировано. В Bamboo например или hudson все замечательно настраивается.
hudson, а вірніше jenkins :)
Пусть отдел тестирования делает регрессию на тестовых серверах близких к боевым и развеивает страхи и неуверенность сеньоров и лидов:)
Писать тесты, БЛ...!!1АДЫНЧто посоветуете делать?
Разделить стабильную ветку и девелопмент. Но тут уже сложнее чем «одной кнопкой».
И что дадут тесты, если они правят прямо на
«Clean checkout перед каждым билдом — это долго, а еще наши изменения потеряются»
И что дадут тесты, если они правят прямо наЧееее?CI-сервере сорцы?
«Clean checkout перед каждым билдом — это долго, а еще наши изменения потеряются»При 1,7 Гб сорцев, оверхед максимум 5 минут (полный билд
ох это как то так круто что я в это практически не верю. Круче только по фтп на продакшене править. Или тоже высоко котируете данный способ? :P
Я за VCS. Но ребята умудряются комментить несобирающийся код в 3rd-party библиотеках, а потом с круглыми глазами спрашивать «А что мне было делать? Надо же было собрать быстро.»
Меняю свой ответ
Что посоветуете делать?
Валитенахоттуда!
«А что мне было делать? Надо же было собрать быстро.»
Это же очевидно: если закомментил код, для того чтобы собрать и все таки собралось — закоммить изменение. Меняешь на билд-сервере — коммить с билд-сервера, создавай баг мол «фигня эта ваша заливная рыба, пришлось выкинуть, чините».
Оно собралось. Но в результате того, что 3rd-party не собирается/тестируется после каждого билда — во время работы начались проблемы.
Дядя просто создавал новую конфигурацию и ему было лень грамотно собрать и запустить тесты для сторонней либы.
Он зарепортил, что всё ок и выдал продукт.
Он зарепортил, что всё ок и выдал продукт.
тогда только массовые расстрелы для спасения демократии
Вот именно, что правят на серваке.
Это как? Нормальные ЦИ сами делают чекаут, даже если что-то поменять, то оно затрется. Что это у вас за чудо такое?
Кстати, сталкивался с подобной ситуацией, когда требовалось за 1 коммит (и вообще без коммита) получить полнстью рабочую программу. При этом, разумеется, результат (патч) можно было получить только после
И чё? Начнём спор о крутизне 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 — то это уже нарушенный процесс или его отсутствие, а не боязнь чего-то.
Włodzimierz Rożkow
Viacheslav
Kostiantyn Shchepanovskyi
Oleksiy Pastukhov
Bogdan Shyiak
Paul C
Denys Valchuk
Васисуалий Лоханкин
Ноу Брюква
flyman
Alexandr Gavriluk
Mykola Gurov
Norb
Станіслав Малкін
proger
Alex Svetlov
двадцатитрёхлетний сениор
Alex Svetlov
двадцатитрёхлетний сениор
чччч ччч
Виталий Кеценко
Volodymyr Yelnikov
Mikhail Boiko
Insider
Insider
Igor Rogov
Paul C
Нестор Иванович
Нестор Иванович
Андрій Серняк
Bohdan Chechyn
Bogdan Shyiak
Vasyl Lytovchenko
Oleksiy Pastukhov
Sergey Ponomarev
Sergey Ponomarev
Yaroslav Fedevych
Євген Козлов
Sandro Zakusilov
flyman
92 коментарі
Додати коментар Підписатись на коментаріВідписатись від коментарів