Иван Шумов, Буду признателен, если разъясните мне один момент.
Про дев-ветку я понял, это нормальная практика.
Здесь больше вопрос в следующем:
Возьме ситуацию, приближенную к моей: делаем АПИ.
1) Разработчик пилит фичу, делает МР
2) Проходят автотесты.
3) На данном шаге ручка работает, все ок, но ее никуда не выкатывали.
4) Делается Код-ревью
5) Мержится в девелоп
6) Выкатывается в окружение для тестирования.
7) Находится косяк при выкатке/выполнении кода (забыли протестить какую-то исключительную ситацию)
8) Создается новая ветка с фиксом, переходим на шаг 1.
9) Все хорошо, все везде работает, но кол-во коммитов по одной задаче в девелоп-ветке больше, чем один, что засоряет историю.
В данном алгоритме как раз не хватает выкатки этой ветки куда-нибудь для теста всяких ситуаций.
Возможно, я неправильно вас понял и привел неверный алгоритм.
Буду рад, если вы меня поправите и/или покажете свой алгоритм работы в таких ситациях.
(Только не говорите, что это все должно быть покрыто тестами и таких ошибок быть не должно - такое всегда есть и будет).
Я работал с таким процессом:
1) Пилим МР в девелоп ветку.
2) Проходят автотесты
3) Присваиваю МР тег deploy_test
4) Запускаю сборку тестового окружения.
5) Сборка ищет все МР с данным тегом и у которых автотесты выполнены и как-то мержит их с девелопом. Если мерж не может быть автоматически, да, деплой отклоняется и разрабы должны договориться между собой и ктото снять метку, но такие ситации у нас были нечасто)
6) Все эти ветки заливаются в тест, разрабы могут проверять успешность выкатки и сами подергать ручки для проверки на различных объектах
7) Код-ревью
8) Мерж в девелоп
Да, здесь также могут быть косяки что когда тестер дойдет до исключения, придется пилить фикс-МР, но это опять же, гораздо реже, чем вообще без выкатки. Я, например, часто сталкивался с ситуацией, когда просто не покрываешь тестами то, что некоторые поля из БД/АПИ могут отсутствовать в ответе и, когда выкатываешь на тест, тебе приходят такие данные и код падает.
Подытожив, меня интересует момент, как можно в МР проверить код на выкатку и так, чтобы другие разрабы не теряли свой код.
Если в репе больше одного открытого MR - пора бежать бить тревогу
Не понимаю, как это работает при 2+ разработчиках.
2 разработчика делают две задачи, никак между собой не связанные. Оба в один момент времени сделали Мерж-реквест и хотят это проверить на контуре, приближенном к боевому (/ отдать тестировщикам, /пройтись Я.Танком по ручкам и т.п. - причин множество).
И как им тестить? По очереди - это ж бред. Для каждого разраба свой тестовый контур - неправильно, он должен быть приближен к боевому, а это у же дев-машина получается, да и тестировщикам неудобно. Вначале вмержить в мастер все - а если баги, так и делать ветки по починкам?
sim3x, Эм.. не совсем понял. Допустим след.ситуацию:
Была добавлена таблица в БД. Для примера таблица комментариев. Фронтенду надо сделать вывод списка комментариев - сам список бекендом уже передается в контекст. Для фронтенда надо, чтобы список был непустым, т.е. какие-то тестовые данные, которые не должны попасть на прод.
Заполнять ручками данные - точно не решение.
какое в вашем случае будет решение? Если фикстуры лучше не использовать, то у меня нет решений
Я правильно понял, что вы предлагаете след.структуру:
Есть вагрант, где командой vagrant up поднимается сервер, запускаются pip install, migrate, runserver (хоть скриптом, хоть руками - без разницы) и он находится на локал.компе разработчика.
Но тогда как обновлять данные в БД? этот вопрос мне очень интересен.
У нас вначале еще была проблема с медиа-файлами (их очень много), но мы их перенесли в S3 и теперь этой проблемы нет. Как сделать такое же с БД и надо ли, я не знаю.
sim3x, > Для фронтендера нет никакой проблемы запустить ./manage.py runserver и получить себе работающее приложение.
Прошу прощения за некропостинг.
А еще не забывать ./manage.py migrate, pip install -r reqs/dev.txt, развернуть celery (+ redis/RabbitMQ) и БД.
А еще надо учитывать, что многие фронтендеры сидят на винде (птмчт там есть фотошоп,а денег на мак нет) и там с этим есть некоторые проблемы.
Плюс если в миграциях создаются новые таблицы, то надо еще тестовые fixtures или брать дамп бд у кого-либо и уметь его грузить.
Вобщем сложностей для фронтенда очень много создается.
Поэтому мне тоже интересно, как делают другие. Меня не интересует СПА.
Мы попробовали на одном проекте бек на джанго (API), фронт на ExpressJS (Node). Удобно тем, что можно переключаться между серверами (фронт можно направить получать данные из боевого, тестового или дев сервера, просто поменяв переменную в окружении).
sim3x: Ничего подобного. Для этого и сделана функция on_commit, а раньше для этого были сторонние хуки, потому что такая проблема действительно есть, когда селери таск начинает выполняться раньше, чем происходит запиь в базу.
sim3x: если убрать on_commit, тогда в селери будет отдаваться id заказа, когда сам заказ еще не сохранился в базе, с этим я точно сталкивался. атомик наверное уберу, да, раньше было без него.
sim3x: Была ситуация на nginx произошла 499 ошибка - пользователь не дождался ответа. Если я правильно помню, тогда заказ сохранился, а итемы в заказе нет. После этого я решил использовать одну транзакцию для заказа, чтобы предотвратить такие случаи - заказ либо должен создаться нормально, либо вообще не должен создаться.
Немного не понял, что значит "Твой кейс - использовать селери". таск create_order_print_archive итак выполняется на селери.
Хз, статус 'processed' стоит по дефолту, нигде в коде он не проставляется. А после этого бага у заказа именно этот статус. Если и перезатирается, то походу транзакцией, которая выполняется в блоке atomic, но мне это кажется безумием... Хотя триггер надо бы повесить, да.
Maa-Kut: Но в логе селери ошибок никаких нет, показано, что задача выполнена за определенное время и вернула True. В задаче никаких перехватов ошибок нет. И я даже перед самым return принтил статус заказа и он отображался, как new
Maa-Kut: Имхо немного не так: если транзакция не выполнилась, блок в функции on_commit вообще не вызовется + у меня обратная ситуация: транзакция ОК, а задача не закоммитилась
Таких конфигов на первом сайте нет. Настроен он был давненько, мб после того версия обновлялась, но конфиг не менялся (django-celery==3.0.17, celery==3.0.19)
Сергей, спасибо за ответ. Да, согласен, уронить не сможет, но сможет исходники сайта скопировать, короче навредить может.
chroot - слышал, но не пробовал ни разу. Спасибо за наводку, буду курить man'ы
Написано
Войдите на сайт
Чтобы задать вопрос и получить на него квалифицированный ответ.
Про дев-ветку я понял, это нормальная практика.
Здесь больше вопрос в следующем:
Возьме ситуацию, приближенную к моей: делаем АПИ.
1) Разработчик пилит фичу, делает МР
2) Проходят автотесты.
3) На данном шаге ручка работает, все ок, но ее никуда не выкатывали.
4) Делается Код-ревью
5) Мержится в девелоп
6) Выкатывается в окружение для тестирования.
7) Находится косяк при выкатке/выполнении кода (забыли протестить какую-то исключительную ситацию)
8) Создается новая ветка с фиксом, переходим на шаг 1.
9) Все хорошо, все везде работает, но кол-во коммитов по одной задаче в девелоп-ветке больше, чем один, что засоряет историю.
В данном алгоритме как раз не хватает выкатки этой ветки куда-нибудь для теста всяких ситуаций.
Возможно, я неправильно вас понял и привел неверный алгоритм.
Буду рад, если вы меня поправите и/или покажете свой алгоритм работы в таких ситациях.
(Только не говорите, что это все должно быть покрыто тестами и таких ошибок быть не должно - такое всегда есть и будет).
Я работал с таким процессом:
1) Пилим МР в девелоп ветку.
2) Проходят автотесты
3) Присваиваю МР тег deploy_test
4) Запускаю сборку тестового окружения.
5) Сборка ищет все МР с данным тегом и у которых автотесты выполнены и как-то мержит их с девелопом. Если мерж не может быть автоматически, да, деплой отклоняется и разрабы должны договориться между собой и ктото снять метку, но такие ситации у нас были нечасто)
6) Все эти ветки заливаются в тест, разрабы могут проверять успешность выкатки и сами подергать ручки для проверки на различных объектах
7) Код-ревью
8) Мерж в девелоп
Да, здесь также могут быть косяки что когда тестер дойдет до исключения, придется пилить фикс-МР, но это опять же, гораздо реже, чем вообще без выкатки. Я, например, часто сталкивался с ситуацией, когда просто не покрываешь тестами то, что некоторые поля из БД/АПИ могут отсутствовать в ответе и, когда выкатываешь на тест, тебе приходят такие данные и код падает.
Подытожив, меня интересует момент, как можно в МР проверить код на выкатку и так, чтобы другие разрабы не теряли свой код.