Какие стандарты Ваша команда осуществляет для развертывания кода основной версии?
Вам может понадобиться groupby два раза, затем join результат назад
s=df.groupby(['id','year']).agg({'avg':'mean','sum':'sum','div':lambda x : x.iloc[0]/x.iloc[1]})
s=s.unstack()# here is reshape
s.columns=s.columns.map('{0[1]}_{0[0]}'.format) # here is flatten the multiple index
s
Out[723]:
2011_avg 2012_avg 2011_sum 2012_sum 2011_div 2012_div
id
101 0.450 0.250 3 5 2.0 1.5
102 0.505 0.305 12 17 6.0 2.0
s2=df.groupby(['id']).agg({'sum':'sum','div':lambda x : x.iloc[0]/x.iloc[1]})
Finaldf=s2.join(s)# join back
Finaldf
Out[729]:
sum div 2011_avg ... 2012_sum 2011_div 2012_div
id ...
101 8 2 0.450 ... 5 2.0 1.5
102 29 6 0.505 ... 17 6.0 2.0
[2 rows x 8 columns]
8 ответов
Minimun:
- модульные тесты работают
- интеграционные тесты работают
- развертывать на этапе тестирования ok
- ручная короткая проверка на этапе тестирования
Лучше:
- модульные тесты работают
- checkstyle ok
- интеграционные тесты работают
- показатели, такие как jmeter и тестовое покрытие пройдено
- развернуть на этапе тестирования ok
- некоторые ручные тесты на этапе тестирования
наконец развернуть на стадии производства
Все модульные и интеграционные тесты работают автоматически, лучше всего на сервере непрерывной интеграции, например CruiseControl , выполненном ant или maven . При разработке веб-сервисов тестирование с помощью soapui работает нормально.
Если используется база данных, перед развертыванием выполняется автоматическое обновление (например, с помощью Liquibase ). Когда используются внешние сервисы, При разработке веб-приложений будет полезна проверка HTML на некоторых страницах. Ручная проверка макета (например, броузеров ) будет полезна.
(Все примеры ссылок для разработки на Java)
И последнее (но не менее важное): все ли приемочные тесты проходят ? Продукт то, что хочет владелец? Сделайте с ним живой обзор тестовой системы, прежде чем продолжить!
Я главным образом делаю веб-разработку, таким образом, мои объекты могут отличаться от Ваших. Просто первое, что пришло на ум...
- Удостоверьтесь, что все веб-сервисы актуальны
- Удостоверьтесь, что вся база данных, scripts/changes/migrations, уже развертывается на рабочем сервере
- Минута весь js и файлы CSS.
- Удостоверьтесь, что все тесты единицы/функциональной/интеграции/Селена передают (Мы стремимся к 95% + тестовое покрытие, в то время как мы разрабатываем, таким образом, они обычно довольно точны в определении проблемы),
Существует больше, я знаю, что существует, но я не могу думать ни о ком прямо сейчас.
- видимых ошибок нет? ок
- unit test работает? хорошо (некоторые проигнорировали) ну хорошо
- настроил, конечно. ok
- запись в журнал ошибок? конечно ! :-) нам это нужно! чтобы исправить ошибки!
- все на cruisecontrol.net хорошо.
Каждый проект индивидуален, однако, как правило, я стараюсь сделать основные вещи, которые я пытаюсь сделать, прежде чем позволить коду уйти в мир.
Ни в коем случае порядок:
1) Идентификатор версии в том месте, где он может быть найден пользователем позже, он должен быть уникальным для этого выпуска. (очень часто «номер версии», связанный с распространяемым файлом, библиотеками и исполняемым файлом, или пользователь, видимый из диалогового окна «о». Может быть числом в хорошо известном регистре или смещением в прошивке)
2) Снимок точный код, использованный для выпуска релиза. (для этого подходит метка или ветка выпуска в системе SCM)
3) Все инструменты, необходимые для воссоздания источника, должны быть отмечены и заархивированы (без этого источник с шага 2 становится ограниченным в использовании)
4) Архив фактического выпуска (копия точного выпущенного установщика, который знает, что через 7 лет ваши инструменты не смогут его собрать, но теперь, по крайней мере, у вас есть исходный код и устанавливаемый файл для исследования.
5) Набор задокументированных изменений между этой версией выпуска и предыдущей, также известной как Примечания к выпуску (мне нравится использовать стиль добавления в список, чтобы все изменения выпуска были доступны для пользователя в одном месте)
6) Цикл тестирования выпуска кандидата завершен. Использование распределенной созданной нагрузки и тестирования с использованием полного / проверенного плана тестирования, чтобы убедиться в работоспособности основных функций, все новые функции присутствуют и работают по назначению.
7) Отслеживание дефектов показывает, что все невыполненные элементы помечены как a) исправлены b) не являются дефектами c) отложены.
Вы можете добавить много других шагов в зависимости от домена или стиль разработки, но я бы сказал, что большая часть программного обеспечения «должна» выполнять вышеуказанные шаги в каждом выпуске. YMMV.
Удачи, штурм замка.
- Стиль кода (автоматизированный)
- Автоматизированные тесты (модульные и интеграционные тесты)
- Ручные тесты (включая этапы тестирования и бета-тестирования)
- Инструмент тестирования на проникновение Whitebox (автоматический)
- Инструмент тестирования проникновения Blackbox (автоматизированный)
- Ручной мониторинг исключений / ведения журнала на этапах тестирования / бета-тестирования перед развертыванием
- возможность вернуться к предыдущей версии в любое время
- проверка кода и «незаконные проверки»
Для веб-приложений и внутренних приложений одно предложение в дополнение к другим предложениям.
Обязательно привлекайте команду по эксплуатации / развертыванию, чтобы вы не доставляли программное обеспечение, для которого требуется больше серверов, чем у них (не думайте, что люди, продвигающие требования, уже сделали это).
Недавно мы выпустили крупный релиз, так что это все еще свежо в моей памяти. Мы создаем приложение для Windows с графическим интерфейсом пользователя, для которого мы выпускаем двоичный исполняемый файл, поэтому мой список обязательно будет существенно отличаться от списка для веб-версии.
Кандидаты на выпуск отправляются группе тестирования. Им нужно как минимум несколько дней, чтобы поиграть с ним. Если они обнаруживают какие-либо ошибки, которые мы считаем препятствующими их появлению, выпуск прерывается. Это предполагает, что у вас есть команда тестирования. Мы удаляем релиз-кандидата только в том случае, если с момента его сборки прошла хотя бы одна неделя.
Все автоматизированное тестирование должно работать и проходить. Автоматическое тестирование считается дополнением к живым тестерам.
Любые ошибки, отмеченные как «блокирующие», должны быть устранены для окончательной сборки.
Рекламные материалы должны быть готовы (в нашем случае, обновление веб-страницы и информационный бюллетень по электронной почте). Торговых посредников предупреждают о том, что релиз выйдет за несколько недель, чтобы они также могли подготовить свой материал. В основном это не проблема программистов, но мы проверяем маркетинговые заявления на точность.
Лицензирование необходимо обновить, чтобы отразить используемую нами защиту от копирования. В наших бета-версиях и выпусках используются разные модели лицензирования, и это изменение требует усилий по программированию.
Необходимо обновить установщик и лицензионное соглашение. Поскольку в бета-версиях есть установщик, это обычно просто изменение текста, но все же программисты должны фактически обновить сценарий установки.
Любые ссылки на бета-версию должны быть удалены из самого приложения. К сожалению, мы упустили некоторые из них.
Файлы справки и руководства должны были быть полностью обновлены и отредактированы, поскольку они были частью пакета выпуска.
Если бы были ошибки, которые нельзя было исправить вовремя, мы бы хотя бы попробовали чтобы уменьшить ущерб - например, обнаружить, что произошла такая-то ошибка, и прервать операцию с сообщением об ошибке с извинениями. Это в огромной степени способствует воспринимаемой стабильности продукта.
Несомненно, трудности основного выпуска заключались не в проблемах программирования, а в административных / маркетинговых проблемах. Многие из этих вещей требовали внимания программиста - помощь с установщиками, вычитка списка функций, чтобы убедиться, что все это не ерунда, корректура технических разделов руководства, обновление лицензий и т. Д. Основным техническим отличием было изменение исправление ошибок для устранения ошибок.
поскольку они были частью пакета выпуска.Если бы были ошибки, которые нельзя было исправить вовремя, мы бы, по крайней мере, попытались смягчить ущерб - например, обнаружить, что возникала такая-то ошибка, и прервите операцию, выдав сообщение об ошибке. Это в огромной степени способствует воспринимаемой стабильности продукта.
Несомненно, трудности основного выпуска заключались не в проблемах программирования, а в административных / маркетинговых проблемах. Многие из этих вещей требовали внимания программиста - помощь с установщиками, вычитка списка функций, чтобы убедиться, что все это не ерунда, корректура технических разделов руководства, обновление лицензий и т. Д. Основным техническим отличием было изменение исправление ошибок для устранения ошибок.
поскольку они были частью пакета выпуска.Если бы были ошибки, которые нельзя было исправить вовремя, мы бы, по крайней мере, попытались смягчить ущерб - например, обнаружить, что возникала такая-то ошибка, и прервите операцию, выдав сообщение об ошибке. Это в огромной степени способствует воспринимаемой стабильности продукта.
Несомненно, трудности основного выпуска заключались не в проблемах программирования, а в административных / маркетинговых проблемах. Многие из этих вещей требовали внимания программиста - помощь с установщиками, вычитка списка функций, чтобы убедиться, что все это не ерунда, корректура технических разделов руководства, обновление лицензий и т. Д. Основным техническим отличием было изменение исправление ошибок для устранения ошибок.
мы, по крайней мере, попытаемся уменьшить ущерб - например, обнаружить, что возникает такая-то ошибка, и прервать операцию, выдав сообщение об ошибке с извинениями. Это в огромной степени способствует воспринимаемой стабильности продукта.Несомненно, трудности основного выпуска заключались не в проблемах программирования, а в административных / маркетинговых проблемах. Многие из этих вещей требовали внимания программиста - помощь с установщиками, вычитка списка функций, чтобы убедиться, что все это не ерунда, корректура технических разделов руководства, обновление лицензий и т. Д. Основным техническим отличием было изменение исправление ошибок для устранения ошибок.
мы, по крайней мере, попытаемся уменьшить ущерб - например, обнаружить, что возникает такая-то ошибка, и прервать операцию, выдав сообщение об ошибке с извинениями. Это в огромной степени способствует воспринимаемой стабильности продукта.Несомненно, трудности основного выпуска заключались не в проблемах программирования, а в административных / маркетинговых проблемах. Многие из этих вещей требовали внимания программиста - помощь с установщиками, вычитка списка функций, чтобы убедиться, что все это не ерунда, корректура технических разделов руководства, обновление лицензий и т. Д. Основным техническим отличием было изменение исправление ошибок для устранения ошибок.
Это в огромной степени способствует воспринимаемой стабильности продукта.Несомненно, трудности основного выпуска заключались не в проблемах программирования, а в административных / маркетинговых проблемах. Многие из этих вещей требовали внимания программиста - помощь с установщиками, проверка списка функций, чтобы убедиться, что все это не ерунда, корректура технических разделов руководства, обновление лицензий и т. Д. Основным техническим отличием было изменение исправление ошибок для устранения ошибок.
Это в огромной степени способствует воспринимаемой стабильности продукта.Несомненно, трудности основного выпуска заключались не в проблемах программирования, а в административных / маркетинговых проблемах. Многие из этих вещей требовали внимания программиста - помощь с установщиками, вычитка списка функций, чтобы убедиться, что все это не ерунда, корректура технических разделов руководства, обновление лицензий и т. Д. Основным техническим отличием было изменение исправление ошибок для устранения ошибок.
Оно похоже или идентично инструменту отслеживания ошибок. Могут произойти следующие вещи:
Кто-то просматривает запрос («кто-то» может быть менеджером по продукту, менеджером проекта и / или руководителем группы разработки) и решает, рассматривать ли его дальше.
Если запрос не немедленно отклоняется, затем передается кому-то (может быть, архитектору или руководителю группы разработчиков),
- The application is tested in many possible scenarios (different OS, database engines, configurations and third party applications).
- All the features of the application are tested: many times happened to us that a change in a feature broke another one thought unrelated, shit happens, so we have to minimize it.
- The setup or deployment works in all the scenarios too
- The setup is able to upgrade former versions