Установка SVN для лучшего Удовлетворения Dev-> QA-> Напоминание
потому что вы только возвращаете текст «JSON posts»
, поэтому возвращайте то, что вы хотите получить
как json response ：
return jsonify({'status': 0, 'msg': 'success'})
detail
[ 111]пример вызова:
requests.post('http://0.0.0.0:5000/postjson', json={'a':'b'}).json()
6 ответов
используйте ветвление и слияние
Мы делаем следующее:
Когда мы выпускаем, мы создаем текущее ответвление выпуска. Мы делаем исправления ошибок здесь между выпусками, затем объединяем их назад с нашей соединительной линией.
Мы разрабатываем на соединительной линии и когда мы готовы выпустить, мы заставляем QA перейти. Мы тестируем и закрепляем на нем и затем выставляем его, и это становится нашим текущим ответвлением выпуска.
Проверьте сообщение в блоге Scott Cowan:
http://sleepoverrated.com/archive/2007/12/buildknowledgepromotingyourbuild/
У него есть большая статья о продвижении Вашего кода к различным средам. Это будет включать запись некоторых сценариев сборки, но улучшит процесс. Это позволит этому также быть некоторыми, что автоматизировало.
У Вас должен быть единый репозиторий, который может быть проверен или экспортирован во время развернуть процесса.
У нас также есть подобная установка. Разработчики проверяют локальную рабочую копию и разрабатывают в их dev среде. Когда мы готовы к deloy подготовить, или QA, как Вы называете его, мы делаем экспорт svn в ту среду (часто головы, но мы всегда отслеживаем определенный пересмотр).
Во время процесса QA мы продолжаем разрабатывать в dev и развертываться к QA.
Наконец, когда мы готовы к производству, мы экспортируем правильный пересмотр из репозитория в продуктивную среду.
Работает отлично!
[Редактирование: до 'это ветвление' - что Вы описываете, вероятно, больше похож на отслеживание изменений. ветвление является, однако, очень важной техникой для управления различными строками разработки. это не должно быть перепутано с наличием другого ответвления для каждого этапа (dev, этапа, живого), обязательно]
Это хорошо работает, если Вы работаете над единым потоком разработки с легко подтвержденными задачами. Но это окажется более сложным с несколькими потоками разработки и возможностью задач, вытаскиваемых или отложенных. Вам затем была бы нужна некоторая зависимость времени в рамках Вашего приложения. Вы могли также использовать что-то как ответвления функции, которые объединяются назад в соединительную линию, после того как функция создается.
У нас есть подобная схема. В SVN у нас есть 3 ответвления, trunk, PREPROD и PROD. Каждый раз, когда новая возможность готова попробовать, это, объединяются в PREPROD ответвление (использующий только определенные числа пересмотра и только для определенных файлов), если это передает QA, это фиксируется и объединилось в PROD ответвление. Когда изменения фиксируются в PROD ответвление, они автоматически развертываются во всех рабочих серверах. За исключением при тестировании новых возможностей, PREPROD и PROD равны.
У нас есть ответвление разработки для каждого bugfix, функции или задачи, и включенные проекты имеют тенденцию иметь несколько ответвлений sub.
Первоначально это - вид странного создания нового ответвления для просто одного линейного кода, фиксируют, но это позволяет объединять соединительную линию в ответвление, затем регрессионное тестирование и наконец объединяться назад в соединительную линию.
Идеально это означает, что что-либо объединилось в соединительную линию, не повредит сборку, и это означает, что Вы не боитесь фиксации Вашего кода для создания хрупкой сборки.
Я часто использую несколько ответвлений для одной проблемы, проверяя различные решения, все еще извлекая пользу из SCM.
Мы также отмечаем определенные версии или выпуски, позволяя быстрое развертывание, базирующееся прочь известного хорошего кода.
Много наших веб-систем использует svn:externals, которые указывают на определенные версии зависимостей, такие как библиотеки и код поставщика. Развертывание взято от внешних пользователей, а не прямого контроля или экспорта.