Простой способ улучшить качество релиза в среде RAD

Здесь немного предыстории - мы небольшая команда (из 5) разработчиков RAD, отвечающая за внутреннюю разработку программного обеспечения в большой компании, не занимающейся разработкой программного обеспечения. «Внутреннее программное обеспечение» варьируется от настольного .NET-приложения, использующего сервер MSSQL в качестве бэкэнда, до сценариев Python, работающих в фоновом режиме, до документов и шаблонов MS Word - зоопарка технологий.

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

Пока все звучит хорошо, но есть проблема - будучи командой RAD, нам приходится часто выпускать, и не будет дня, когда мы выпустим новые версии одного или двух приложений (или это может быть скрипт, обновленный документ Word). Консольное приложение C ++ и т. Д.) В производство. Мы проводим тестирование разработки и также привлекаем конечных пользователей, позволяя им запускать программное обеспечение в среде UAT ...

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

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

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

2. Мы не проводим проверки кода - но мы начнем проверять код до того, как один из нас вернется в набор изменений. Я также думал о «обзоре развертывания» - в основном один из разработчиков должен сидеть рядом с другим, наблюдать, как он / она выполняет развертывание программного обеспечения (копировать двоичные файлы, обновлять конфигурации, добавлять новую таблицу в базу данных и т. Д.) - обычно это только занимает 5-10 минут, так что это не займет много времени "обзор развертывания".

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

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

+1 за прикосновение к великой теме. Когда мы делаем линию разработки «Выпускать раньше, часто выпускать», вещи набирают обороты, и по мере накопления импульса возникает много таких проблем (как вы описали), с которыми мы не очень готовы справиться. Худший страх - это когда люди видят скорость врагом хорошей работы.

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

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

2. Определите ключевые точки отката.
Мы все знаем, что ошибки появятся, поэтому нам необходимо обеспечить эффективный вариант отката, который работает чаще всего. Снова и снова мы дорабатываем (с соотношением примерно 1 к 10 в нашем случае) наиболее распространенный выпуск, который работает везде наиболее надежным образом. Общее количество выпусков может быть много, но если что-то пойдет не так, запасной вариант будет выбран несколькими, и вам больше не придется отступать. Один из самых простых способов узнать лучший запасной вариант - увидеть, какой самый ранний выпуск, который работал дольше всего в производстве, без особых проблем.

3. Различайте рискованные и стабильные или небольшие исправления ошибок.
Когда мы знаем, что у нас есть серьезные изменения в алгоритме, более вероятно, что ошибки могут появиться в сценариях, которые не все предусмотрены. Где, как бывают моменты, когда проблемы очень малы (или хорошо понятны), а также мало рискуют. У НЕ клубу такие функциональные и простые ошибки в тех же выпусках. Всегда сначала исправляйте меньшую ошибку, которая должна идти везде, где требуется. Делайте специальные выпуски для специальных наборов функций, в лучшем случае вы можете отказаться от этой функции, но все другие важные ошибки все еще исправлены в предыдущем выпуске.

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

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

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

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

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

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

10. Последнее, но не менее важное.
Учитесь часто возвращаться к белой доске. Чем больше вы переосмыслите как том, что эта функция была бы частью нашего самого начального дизайна, как бы мы думали о дизайне в то время? Иногда самая большая проблема с добавочной работой заключается в том, что мы слишком ограничены порядком функциональности, который мы создали сначала, и довольно часто не можем вернуться к основам. Хитрость заключается в том, чтобы продолжать видеть, как мы будем обобщать, а не приспосабливать эту новую функцию или сценарий. Это требует, чтобы дизайн оставался актуальным, и это происходит, только если мы часто возвращаемся к чертежной доске. Кроме того, когда присоединяются программисты нового поколения, они становятся частью интеллектуального центра, а не просто устанавливают патчи.

РЕДАКТИРОВАТЬ
11. Следите за обходной путь и дизайн пробелов.
Довольно часто мы испытываем давление сроков, чтобы исправить ошибку и выпустить ее в производство. Тем не менее, когда ошибка находится на уровне разработки, довольно много вещей нужно изменить, но часто люди исправляют некоторые короткие пути, чтобы уложиться в срок. Это нормально . Однако по мере увеличения числа таких обходных решений код становится хрупким. Следите за тем, сколько пробелов в дизайне уже устранено. Как правило, когда вы согласовываете сроки с руководителем проекта, лучше всего поручить ему / ей сделать это в кратчайшие сроки, чтобы сохранить производство, но мы также будем иметь сроки и ресурсы, чтобы получить постоянное решение.

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

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

Отставание | Делать | Выполнено

Однако, это быстро развилось, чтобы отразить наш фактический процесс:

Отставание | Разработка | Девиация Тест | UAT | Готово | Выпущенный

Наряду с платой у нас есть правило, что каждая задача / функция должна тестироваться другим разработчиком (а также разработчиком, который реализовал функцию). Таким образом, к моменту, когда карта достигнет столбца «Готово», она должна быть проверена как минимум двумя разработчиками, а также проверена приемлемостью пользователя.

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

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

Другие ссылки, которые я нашел полезными:

Канбан применяется в разработке программного обеспечения: от Agile до Lean

Система Канбан для разработки программного обеспечения - Видео

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

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

• «Lean Software Development » Мэри и Тома Поппендейков (Marin and Tom Poppendeick) - отличное пособие для людей, заинтересованных в изучении того, как выявлять «отходы» и что делать с изменяющимися процессами, чтобы они стали более экономными и эффективными.
• Head First Development Software от Дэна Пилона и Расса Майлза на первый взгляд немного похожа на одну из этих книг для «пустышек», но, немного оглядываясь на хаотичный стиль презентации, она содержит большую часть информации, касающейся основ разработки программного обеспечения. и имеет краткое описание о Test Driven Development.
• Знакомство с BDD - это страница Дэна Норта, посвященная разработке, управляемой поведением, или, возможно, вы бы предпочли вики BDD . Это начальные ссылки для BDD, и вы, вероятно, захотите изучить инструменты и структуры, которые помогут вам. Важно понимать, что BDD фактически является TDD, взятым на более высокий концептуальный уровень. Это позволяет вам думать о тестировании так же, как вы думаете о спецификациях, и тестировать на том же языке, который вы используете при написании спецификаций. Платформы, как правило, интегрируются с другими инфраструктурами модульного тестирования, поэтому вы получаете лучшее из обоих миров, если решите, что ваше тестирование не обязательно выиграет от синтаксиса BDD.
• Статья по разработке гибкого программного обеспечения Википедии - хороший учебник, посвященный гибкой разработке программного обеспечения, и содержит ряд полезных ссылок и ссылок на статьи некоторых наиболее уважаемых людей сообщества разработчиков.

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

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

Если вы чувствуете, что ваши процессы просто нуждаются в настройке, но вы обеспокоены тем, что ваша цепочка инструментов не совсем соответствует вашим потребностям, то, возможно, посмотрите на улучшения там. Как минимум, продукт интеграции с непрерывной интеграцией (например, Continuum, Cruise Control или Hudson) и система отслеживания проблем (например, Jira или Redmine) должны быть приоритетом, чтобы помочь вам автоматизировать некоторые процессы сборки и выпуска, и держать ваши ошибки и запросы функций под контролем.

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

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

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

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

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

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

Например, если у вас есть класс, в котором метод может принимать только числа от 10 до 25 (это называется предварительным условием), вы бы добавили оператор assert в начале метода. Когда это утверждение не выполняется, программа немедленно завершает работу, и вы сможете следовать цепочке методов, которые привели к этой ошибке.

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

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