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

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

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

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

Прежде чем я начал, компания развертывала античные методы, такие как FTP, и не было контроля версий.

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

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

113 голосов | спросил ilhan 11 J000000Saturday15 2015, 10:25:03

10 ответов


92

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

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

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

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

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

ответил Philipp 11 J000000Saturday15 2015, 11:02:43
54

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

  

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

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

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

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

  

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

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

Итак, начните с беседы.

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

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

ответил user52889 11 J000000Saturday15 2015, 12:21:22
20

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

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

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

ответил Greg 11 J000000Saturday15 2015, 19:59:39
17

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

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

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

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

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

ответил James Decker 12 J000000Sunday15 2015, 05:12:58
12

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

Разбейте сборку, принесите пончики.

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

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

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

ответил Adam Davis 13 J000000Monday15 2015, 18:19:15
8
  

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

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

  

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

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

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

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

ответил vidstige 13 J000000Monday15 2015, 00:31:27
6

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

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

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

ответил gnasher729 11 J000000Saturday15 2015, 23:13:59
3

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

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

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

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

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

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

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

ответил Keith 13 J000000Monday15 2015, 08:37:50
1

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

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

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

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

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

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

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

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

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

ответил aroth 14 J000000Tuesday15 2015, 13:54:48
0

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

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

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

ответил Rufo El Magufo 13 J000000Monday15 2015, 04:21:21

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132