Мой коллега фиксирует и толкает без тестирования

113

Когда мой коллега считает, что нет необходимости в тестировании на своем ПК, он вносит изменения, фиксирует и затем нажимает. Затем он тестирует на рабочем сервере и понимает, что допустил ошибку. Это происходит один раз в неделю. Теперь я вижу, что он сделал 3 коммита и выполняет развертывание на производственном сервере в течение 5 минут.

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

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

До того, как я начал, компания развертывала с использованием античных методов, таких как FTP, и не было никакого контроля версий.

Я заставил их / нас использовать Git, Bitbucket, Dploy.io и HipChat. Развертывание не является автоматическим, кто-то должен войти в dply.io и нажать кнопку развертывания.

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

Илхан
источник
1
Комментарии не для расширенного обсуждения; этот разговор был перемещен в чат .
Мировой инженер
5
Поскольку вы работаете в Git, используйте запросы pull для принудительной проверки кода, прежде чем переходить в master и развертывать в рабочей среде. Также удалите его учетные данные для входа на сервер развертывания. Централизуйте этот авторитет не-разработчиком. (Между прочим, соблюдение PCI, обеспеченное индустрией кредитных карт, требует этого.)
Barett
3
С точки зрения рабочего места, если вы являетесь сотрудником этого человека, а не каким-то образом его руководителем, вы вряд ли получите какую-то поддержку, «наказав» его. Сосредоточьтесь на сохранении качества кода, а не возмездия за слабые стандарты вашего сотрудника.
Зиббобз
2
Всегда ли запуск в «центральный» репозиторий запускает производственное развертывание? Это определенно не должно.
jpmc26
3
Я прочитал вопрос и сказал себе, что парень должен быть турецким, и вы идете :) проверить это, братан: nvie.com/posts/a-successful-git-branching-model . Вам нужно иметь как минимум две ветви: master и dev, где разработчики переходят только в dev, а после тестирования вы объединяетесь с master и deploy.
Cemre

Ответы:

92

Вам необходим надлежащий процесс обеспечения качества (QA).

В профессиональной команде разработчиков программного обеспечения вы не переходите от разработки к производству. У вас есть как минимум три отдельные среды: разработка, подготовка и производство.

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

Если вы не можете убедить руководство нанять кого-либо для выполнения вашего контроля качества, то, возможно, один из вас может сыграть эту роль для другого. Я никогда не работал с diploy.io, но некоторые системы автоматизации сборки могут быть настроены таким образом, чтобы пользователь мог развертывать как от разработки до подготовки, так и от подготовки к производству, но не делать оба для одной и той же сборки, поэтому второй человек всегда требуется (но убедитесь, что у вас есть несколько резервных сотрудников на время, когда один из вас отсутствует).

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

Philipp
источник
Идея поддержки выполнения QA, когда она включает выпуск в производство, кажется удобной, но не будет реализована из-за разделения функций. Поддержка, отвечающая за поддержку после окончания «тестирования программистов», должна информировать их об изменениях. Это действительно сложно с четырьмя разработчиками и ни с кем другим :-) Если вы измените свой ответ, чтобы напрямую обратиться к настройке OP, то это не будет никакой пользы кому-либо еще ...
Билл Вуджер,
1
@BillWoodger почему? Для них это система «предстоящих изменений и отката». Они не только получают выгоду от просмотра того, что происходит до того, как оно «станет реальностью», но также способ легко вернуться к последней версии, если что-то пойдет не так. Не забывайте, что постановка env - это тестирование конца программиста.
gbjbaanb
1
@gbjbaanb, потому что он ставит поддержку в ту же позицию и повторяет исходную проблему. Поддержка обычно имеет экстренный доступ к производству. Если у них также есть другой доступ, у вас есть проблемы аудита (если это важно). Если кто-то может что- то изменить, то есть проблема. Конечно, Служба поддержки должна знать все, они не должны делать все. Об этом говорит каждый аудитор, с которым я когда-либо был связан, и они убедили меня в этом давно.
Билл Вуджер,
@BillWoodger Я не уверен, что ты говоришь. У знакомых мне производственных команд обычно есть свои собственные процессы развертывания, включающие тестовую среду (просто чтобы сначала проверить глупые ошибки). В небольшой команде нет причин, по которым эта тестовая система не может быть использована разработчиками и службой поддержки. В любом случае никакие изменения не допускаются - он заполняется dev с помощью автоматизации и используется службой поддержки. Не отличается от того, чтобы дать им один и тот же код. Аудиторы озабочены процессами, а не их реализацией (за исключением того, что они, конечно, следуют)
gbjbaanb
1
Аудиторы @gbjbaanb заботятся о людях, имеющих доступ ко всему. Если сотрудник службы поддержки может изменить программу в разработке и запустить ее в производство без какого-либо вмешательства со стороны кого-либо еще, то система подвергается риску. Конечно, с четырьмя сотрудниками ОП в любом случае не существует отдельной «Поддержки», и удовлетворительное разделение функций будет непростым делом.
Билл Вуджер
54

Вы, вероятно, захотите получить сервер разработки, а также, желательно, промежуточную среду. Никто никогда не должен продвигаться от местного производства к производству, кроме их собственного личного сайта. Ваш процесс развертывания должен поддерживать только dev-> staging-> prod. Вы, вероятно, хотите, чтобы кто-то отвечал за подписывание новых выпусков - в зависимости от организации, это может быть руководитель проекта, специальное обеспечение качества или обязанности, которые меняются каждую неделю (с осязаемым напоминанием, например, только человек с пушистой игрушкой на этой неделе попадает в От себя). Тем не менее, сначала обсудите это с вашей командой, чтобы получить бай-ин (см. Ниже).

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

Вы могли бы иметь свой набор тестов (у вас есть один из них, верно?), Включающий проверку, которая определяет, находитесь ли вы на рабочем сервере, и, если это так, отправляет всем в офисе электронное письмо с надписью Looks like $username is testing on prod, watch out. Возможно, публично опозорить вашего коллегу было бы неприятно. Или вы можете создать технические ограничения, такие как IP-адрес, запрещающий вашей команде смотреть на продукт (который вы можете снять, но вы должны оправдать это).

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

Конечно, вы действительно хотите, чтобы это поведение не наказывалось, а чтобы оно прекратилось ?

Я заставил их / нас использовать [...]

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

Итак, начнем с разговора.

Узнайте, почему это происходит (машина вашего коллеги не так хороша для тестирования? Ваш коллега неуверен с ветвями функций или застрял в svn-мышлении, где commit и push одинаковы?), Объясните, почему для вас проблема заключается в том, что непроверенный код идет на dev / staging / prod, и посмотрите, сможете ли вы что-то сделать, чтобы изменить причину этого (ваш коллега, скорее всего, сделает то, что вы хотите, если вы только что сделали более приятным локальное тестирование, чем если бы вы их просто ругали).

Если вы не можете решить эту проблему, и это действительно сводится к расхождению во мнениях, запланируйте групповое обсуждение на следующей ретроспективной встрече, посмотрите, что ваши коллеги делают и думают. Сделайте свое дело, но прислушайтесь к консенсусу. Может быть, ваша команда говорит, что не стоит локально тестировать текстовые исправления, и у вас просто есть правило, что никакие большие функции не попадают в dev без тестирования. Запишите на собрании и зачитайте, что вы вместе решаете о том, что разрешено в каждой среде. Установите дату через пару месяцев, чтобы просмотреть ее, может быть, в ретроспективе.

user52889
источник
10
+1 за разговор. Должно быть общее понимание, что это проблема и почему это проблема. Только тогда может быть любой успех с техническим решением.
Патрик
9
+1 для получения сервера разработки / промежуточных сред. До тех пор, пока за пределами собственной машины не появится реальное место, чтобы подталкивать вещи, такое поведение не является полностью ошибкой сотрудника. На своей машине человек может сделать очень много, и, если уж на то пошло, дополнительная среда часто помогает изменить мыслительный процесс / отношение к тестированию.
Джоэл Коухорн
20

На работе мы избегаем этого, используя Геррит . Gerrit - это система проверки кода, которая выступает в качестве шлюза в вашу основную / производственную ветку Git, которая обычно называется "master". У вас есть отзывы кода, верно? Похоже, вы лично делаете их исключительно. С помощью Gerrit вы переходите к некой промежуточной ветви, которая после того, как вы и ваш коллега успешно выполнили процесс проверки кода, затем Gerrit сливается с вашей основной веткой. Вы даже можете подключить Gerrit к CI-серверу для выполнения модульных тестов, прежде чем кто-либо получит электронное письмо с просьбой рассмотреть изменение. Если у вас нет сервера, на котором вы можете установить инструмент CI, у Codeship есть хороший бесплатный план для использования в качестве доказательства концепции.

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

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

Greg
источник
17

Я рассматриваю это как в значительной степени человеческую проблему - процесс есть и инструменты есть, но процесс просто не соблюдается.

Я согласен с тем, что другие говорили здесь, о возможности того, что это вполне возможно , разработчик в вопросе просто застрял в SVN мышления, а также может думать , что он будет следить за процессом.

Я считаю, что лучший способ решения такого рода проблем, особенно в тех случаях, когда, возможно, нет явного начальника, не вращается вокруг наказания или лишения доступа - это просто приводит к негодованию, и, как вам кажется, вы громкий сторонник следования процесс (всегда есть один, и я был «тем парнем» раньше), вы тот, кто может выдержать больше тепла. Он вращается вокруг того, чтобы сначала договориться о процессе.

Именно здесь могут быть очень полезны структурированные встречи, такие как встречи типа «извлеченные уроки» после крупного производственного инцидента. Постарайтесь, чтобы все согласились, в том числе и с разработчиком, о том, что проверка кода, модульное тестирование, комплексное тестирование и т. Д. Должны проводиться каждый раз (и здесь вы можете начать представлять идею промежуточной среды). Это не должно быть трудно, и это очень разумно. Затем попросите команду вместе выработать твердые правила о том, как это должно быть сделано. Чем больше вносит вклад разработчик, вызывающий проблему, тем больше они будут чувствовать себя приверженными правилам и начнут понимать, почему их поведение было проблемой.

Финальный пункт - никогда не попадать в «ну, это лучше, чем раньше!» ловушка. Всегда есть возможности для улучшения. По моему опыту, люди в ИТ-индустрии после некоторых улучшений начинают соглашаться на то, что у них есть. Затем урегулирование продолжается, пока вы снова не окажетесь в критической точке.

Джеймс Декер
источник
1
Мне действительно непонятно, как «зафиксировать / подтолкнуть, немедленно развернуть в производство и протестировать ваши изменения там и нигде» - это мышление SVN ... Единственная часть этого процесса, в которой будет задействован SVN, - это фиксация. Даже при использовании единственной модели ветвления или управления исходным кодом фиксация не обязательно подразумевает развертывание в производственной среде. Или, по крайней мере, не должно.
jpmc26
@ jpmc26: Риск войны пламени в Git / SVN: Мы унаследовали систему SVN для большей части нашего «унаследованного» кода, но использовали Git для нашей новой работы. Я могу почти гарантировать, что у нас не было правильной настройки SVN и / или мы не использовали ее правильно, но с обработкой веток в Git работать намного проще. Я на 100% уверен, что SVN более чем способен справиться с правильным развертыванием, но я также вижу (из своего несовершенного опыта), как SVN может «меньше вас отговаривать» от правильных действий. В любом случае, это будет только способствующим фактором, и образование пользователя является более важным.
TripeHound
1
@TripeHound Нет аргументов в пользу того, что система git лучше подходит для управления изменениями кода. (Мои возражения по поводу git, как правило, связаны с высокой кривой обучения.) Я хочу сказать, что, хотя git может иметь больше возможностей для управления процессом выпуска, способ настройки инфраструктуры сборки по-прежнему остается основным фактором, влияющим на вашу работу. Выбор контроля источника. У меня была довольно успешная автоматизация сборки и выпуска в SVN в течение достаточно долгого времени, поэтому я не совсем понимаю, что такое «SVN образ мышления» или как он отрицательно влияет на ваш релиз.
jpmc26
2
Тот факт, что вы берете на себя обязательство освоить, не означает, что вы должны развертываться на производстве. Даже если ваш исходный репозиторий / репозиторий svn размещен на сервере prod, это не означает, что это необходимо.
фон Петрушев
12

Это не редкость , особенно в небольших командах. Не придавайте этому большого значения, но сделайте неофициальное правило:

Сломайте сборку, принесите пончики.

Либо 1) Вы будете получать пончики два раза в неделю, либо 2) они будут придерживаться стандарта.

Поднимите это на встрече. Не осуждайте, не называйте никого по имени, но что-то похожее на: «С тех пор как мы ввели стандарты контроля версий и развертывания, все стало намного проще, и сервер работает чаще, чем раньше. Тем не менее, все еще заманчиво выбрать ярлык и отправить его без надлежащего тестирования. Однако это азартная игра, и наш сервер готов к работе. Я предлагаю, чтобы теперь, если кто-либо из нас представит код, который нарушает работу сервера, ответственное лицо приносит пончики для команды на следующий день. "

При желании замените что-нибудь еще на пончики, и не делайте это дорого - обед для всей команды был бы слишком большим, но коробка с пончиками за 5 $, или поднос с фруктами / овощами, или чипсы и соус, и т. Д., И т. Д., Вероятно, будут раздражать Достаточно, чтобы заставить их фактически взвесить риск и удобство пропуска тестирования, не создавая бремени, которое оттолкнет их от команды или компании.

Адам Дэвис
источник
2
Это работает только с офисом. Какова эквивалентная концепция, когда у вас есть распределенная команда удаленных разработчиков, которые все работают из дома?
дата
2
@aroth Для некоторых команд достаточно простого электронного письма от человека, который нарушил сборку. Запланируйте это как «цель непрерывного улучшения процесса» и попросите, чтобы в электронном письме содержалось достаточно информации, чтобы другие могли увидеть, что пошло не так, почему это пошло не так, и что этот человек изменит в своем процессе или что он предлагает команде изменить. процесс, чтобы предотвратить его повторение. Большинство людей ненавидят отчеты и отчеты, и опять-таки достаточно досады, что они могут быть более осторожны, чтобы не сломать сборку в будущем.
Адам Дэвис
8

Теперь, как я могу заставить их ...

Вместо того, чтобы заставлять своих коллег пытаться заставить их взглянуть на вещи с вашей точки зрения. Это сделает все намного проще для всех. Что приводит меня в ...

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

Почему вам больно с проблемами на живом сервере, а не с этим парнем? Вы знаете что-то, что он не знает? Что вы можете сделать, чтобы заставить его видеть вещи, как вы?

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

В общем, старайтесь работать вместе с людьми для решения проблем, а не вовлекать их в процессы, которые не понимают.

vidstige
источник
6

Что хуже всего может случиться? Есть ли у вас достаточно хорошие резервные копии, чтобы можно было исправить ошибку, изменяющую случайные записи в вашей базе данных, восстановив старую версию?

Допустим, у вас есть ошибка, когда вы используете идентификатор записи, и по ошибке сумма счета в центах сохраняется в переменной, используемой для идентификатора записи. Поэтому, если я заплачу 12,34 доллара, запись с идентификатором 1234 будет изменена. Сможете ли вы восстановиться после этого, если программа будет работать в течение нескольких часов, пока ошибка не будет обнаружена? (Если обновлена ​​и правильная запись, и запись 1234, вы обнаружите это только при использовании записи 1234, так что это может остаться незамеченным в течение длительного времени).

Теперь спросите своего высоко мотивированного разработчика, что он думает об этом. Очевидно, он не может утверждать, что он никогда не делает ошибок, потому что он делал это в прошлом.

gnasher729
источник
«У вас есть достаточно хорошие резервные копии», и, даже если это так, хочет ли ваш коллега быть тем маггином, который должен восстановить резервную копию, потому что он сломал сервер? Возможно, он в принципе хотел бы протестировать перед развертыванием, но, поскольку нет тестовой среды, он выбрал самый простой из доступных на данный момент вариантов. Тогда создание кейса для тестового сервера должно быть легким. Кстати, ошибки, которые остаются незамеченными «в течение некоторого времени», пройдут тестирование до развертывания, поскольку проблема таких ошибок - качество тестирования, а не место проведения тестов.
Стив Джессоп
У вас есть не только резервные копии, но и может ли ваш бизнес позволить себе простои, пока идет восстановление? И может ли он позволить себе потерять минуты, часы или даже дни информации, потому что пришлось выполнить откат базы данных? Я бы сказал, что почти во всех нетривиальных случаях ответ - «нет». И даже в тривиальных случаях вы не хотите, чтобы «восстановление резервной копии» было таким, каким вы имеете дело с проверкой непроверенного кода. Должно быть что-то, что гарантирует, что тестирование происходит между моментом, когда код зарегистрирован и когда он достигает производства.
дата
Полностью согласен, поэтому я сказал: «Спросите своего разработчика, что он думает об этом». Он либо полностью введен в заблуждение и считает, что его код не содержит ошибок, либо не осознает, какой ущерб он может нанести. Или третья возможность, он знает и не заботится.
gnasher729
3

Вы четко понимаете различные возможные технологические и технологические решения. Вопрос в том, как управлять коллегой.

По сути, это упражнение по управлению изменениями.

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

Во-вторых, вы работаете в небольшой команде, и, вероятно, стоит попытаться вовлечь всю команду в процесс улучшения.

Настройка регулярных (например, еженедельных) процессов ретроспективы. У всей команды:

  • Определить проблемы
  • Волонтерские идеи по улучшению практики работы
  • Участвовать в реализации этих методов

Естественно следует, что вся команда также помогает обеспечить соблюдение усовершенствованных методов.

Кит
источник
Ретроспектива - это отличный способ рассмотреть и, надеюсь, изменить такое поведение конструктивным образом!
greenSocksRock
1

Я думаю, что вы определили пару проблем:

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

Честно говоря, я думаю, что установка просто безумна. Как минимум, люди, которые могут вручную инициировать запуск в производство, должны быть ограничены набором людей, которым можно полностью доверять, чтобы тщательно просмотреть и протестировать все исходящие изменения (независимо от того, кто является автором изменений), прежде чем инициировать запуск. Предоставление кому-либо разрешения на регистрацию кода также позволяет произвольно инициировать запуск в производство - это просто проблема. Не только от неосторожных и / или некомпетентных разработчиков, но также от недовольных или злонамеренных третьих лиц, которые могут скомпрометировать одну из ваших учетных записей.

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

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

Итак, первым делом стоит исправить процесс развертывания. Либо ограничьте число тех, кто может инициировать запуск в производство, либо включите разумное количество тестирования в процесс автоматического развертывания, либо и то, и другое.

  1. Похоже, вы не установили никаких четко определенных стандартов / принципов разработки.

В частности, звучит так, как будто вам не хватает четкого « определения выполненного » и / или использования того, которое не включает «проверенный код», в качестве решающего фактора при проверке кода в / развертывании кода в производстве. Если бы вы имели это, вместо того, чтобы просто указать, что «хороший код не создается таким образом», вы могли бы сказать, что «этот код не соответствует минимальным стандартам, с которыми мы все согласились, и он должен быть лучше в будущее".

Вы должны попытаться создать культуру, которая четко отображает ожидания разработчиков и стандарты и уровень качества, которые они должны поддерживать. В этом поможет настройка определения done, включающая, по крайней мере, ручное тестирование (или, предпочтительно, автоматические тестовые случаи, которые можно запускать как часть процесса сборки / развертывания). Как может иметь последствия за нарушение сборки. Или более серьезные последствия для нарушения производственной системы. Обратите внимание, что эти две вещи должны быть по-настоящему независимыми, и должно быть совершенно невозможно одновременно сломать сборку и производственную систему (поскольку поврежденные сборки не должны быть развертываемыми).

aroth
источник
0

Вам следует интегрировать процесс непрерывной интеграции + экспертной оценки в компании. Bitbucket делает это легко.

И +1 к серверу разработчиков, предложенному другими пользователями.

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

Руфо Эль Магуфо
источник