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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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