За что можно критиковать такую позицию?

За то что бизнес стоит все это время без нужной фичи

Пока вы там доводите до совершенства какую-то хрень

За то что бизнес стоит все это время без нужной фичи

Вот это хороший заход :)

Но если его не задеплоить, мы будем иметь баги, которые фиксит новый код + баги, которые потенциально могут быть найдены. Или тут смысл в том, что новый код привносит больше багов, чем фиксит? :)

Ну да, теоретически новый код фиксит старые баги, то есть получается что выгодно не деплоить старый код )

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

да божемой, коллеги

всем насрать на код, на баги, на вас, на тестеров

важен в этой схеме только бизнес и его интересы

всё остальное постольку поскольку

У нас баги наносят довольно большой ущерб бизнесу

Если неправильно сгенерится документ, и он потом уйдет заказчикам, то нас отругают а могут и оштрафовать даже. Так что не плевать.

дак вы подумайте, как blast radius снизить для начала

ладно, я поехал короче, Пасха же!

Ущерб от багов?

Ок давай удачи :) Но пасха завтра

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

То есть это какая-то идея anti-fail-fast

Чем реже деплой тем лучше

нет, просто это доп.стейджинг при деплое

транк - тестовый прод для тестеров - прод для бета-юзеров

У нас тоже есть такая тема, называется user-acceptance среда, на ней фичи смотрят аналитики, руководство, и даже часто их демонстрируют клиентам и собирают отзывы

Но вот пропихнуть код на продакшен дальше UA среды крайне сложно

У нас баги наносят довольно большой ущерб бизнесу

Ядерный реактор обслуживаете? :))

Ты недалек от истины

Ты недалек от истины

Старые подходы не во все были плохи, как пытаются показать поколение некст. Просто это было дорого и долго

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

Я не представляю, чтобы скажем софт телеметрии в формуле 1 деплоился так же в стиле "1000 деплоев в неделю" как проповедует новая волна

Иногда надо потестировать тщательно и не на юзерах :))

А какие подходы тогда помогают развивать такой софт? Ну кроме обильного покрытия тестами

Впринципе я вижу у нас как раз тот пример, когда философия девопс не предполагает частые деплои.

А какие подходы тогда помогают развивать такой софт? Ну кроме обильного покрытия тестами

Я не знаю, с подобными системами не работал :( но принцип ограничения возможного ущерба применим всегда. Например выкатывать новую версию сначала для перевозок сахара и воды :)))

Удивительно впрочем какие только задачи индустрия не рещает. Генерировать документы описываюшие класс безопасности -тоже ведь задача и наверно с кучей нюансов

Один из нюансов - практически полное отсутствие хайлоада и очень сложная бизнес-логика.

А как тестировать? Сравнивать пдфки?

Да

Куча людей в офисе сидят и перепроверяют все компоненты

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

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

Ну разве что описать какой-то минимальный DSL для предметной области, но даже не представляю что могло бы таким быть

Ну я про тестирование, Скажем подсмотреть как фронтендеры тестируют финальные интерфейсы. Не скриншоты же они попиксельно равнивают

а из чего пдф генериться ? там латеха нет случаем ?

Да интерфейс у нас убогий, и он вообще не важен.

Вся ценность именно в выходных пдфках и их содержании

а из чего пдф генериться ? там латеха нет случаем ?

Нет, прямо из базы формируем html, а его уже конвертим в pdf

Именно, но задачу проверки пдф можно свести к задаче проверки html которая как то же решена уж наверно

мм по сути у вас тесты то на смысл должны быть

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

хотя можно и к набору ключевых слов свести

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

О так организуйте беседы если у вас именно тут ботлнек, пока все непоймут логику

ну да это работа которую кто-то должен сделать

Это нам придется сотнями часов с ними беседовать, а в это время надо еще новые фичи делать, тестировать, деплоить и апгрейдить инфраструктуру :)

Ну аналитики впринципе этим и занимаются, их там огромная куча.

Ну аналитики впринципе этим и занимаются, их там огромная куча.

а результат их работы все равно непонятен вам ?

В таком виде чтобы его можно было закодировать в виде DSL или чего-то программируемого, результата не существует.

У вас проблемы, что в пдф написано не то или что написано то, но верстка уехала и надпист "НЕ НЮХАТЬ" уехала под дату и не видна?

А в логике там в любом случае адовое спагетти из ифов :(( тоже наверняка решенная проблема. Какие нибудь decision tree

Проблемы верстки есть но их очень мало и они легко фиксятся

В таком виде чтобы его можно было закодировать в виде DSL или чего-то программируемого, результата не существует.

а поменять формат их выхлопа можно ? похоже даже проблема не в требованиях а именно в переводе на язык архитектуры, а это значит аналитики недоделали работу

а поменять формат их выхлопа можно ? похоже даже проблема не в требованиях а именно в переводе на язык архитектуры, а это значит аналитики недоделали работу

Я полагаю это чем-то похоже на то, когда каждая команда пишет свои apache rewrite rules, и в итоге когда они все сливаются в один мега конфиг и там сам черт ноги сломит и не работает иногда :))

Они бизнес аналитики а не системные аналитики, так что архитектуру они нам не смогут построить

а системных нет или архитекторов ?

Проблемы верстки есть но их очень мало и они легко фиксятся

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

Мосты и дома по девопс лекалам никто не строит и на это есть причина :))

а системных нет или архитекторов ?

Архитекторы это мы и есть

И грустно видеть как ветка кода несколько месяцев никак в прод не уходит

А иногда нам вообще фичи заворачивают и говорят выпиливайте их, клиентам это не понравится

ERROR: S client not available

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

я видел аджайл в написании статей, тут тоже можно адаптировать, девопс он не только про инструменты но и про процессы и культуру

https://probusiness.by/experience/3251-zachem-eti-chaynye-ceremonii-eti-bukhgaltery-i-yuristy-polgoda-uzhivalis-s-agile-kak-proshel-eksperiment.html во соус

ну ту часть которая касается инфраструктуры и автоматизации мы внедряем нормально

а канбан доска есть по разработке ?

есть

похоже непомогает если так с фичами работают и с кодом

Почему, помогает

Просто когда мы закрываем наши задачи то это не значит что они пойдут в прод, это значит что руководство начнет их тестить на UA среде и демонстрировать клиентам

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

А мы в это время делаем другую пачку задач

так а для этих этапов тоже канбан есть ?

или они вне доски вашей

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

У нас например может быть 30 задач на старте спринта, а в терминах бизнес задач это 1-2 задачи.

воот, я поэтому и спросил про канбан..

канбан работает когда весь процесс до прода на доске

Так ты предлагаешь ввести еще одну колонку On UA ?

еще 2 на UA и ушло в прод

Хм можно подумать впринципе

при этом если работать по правилам канбана, у вас задачи те что максимально справа будут наиболее приоритетными и фокус будет дотащить до прода, а неначать делать новые

Если так делать по всем правилам я подозреваю что на канбан доске будут сотня задач, 7 колонок и человек 15-20 девов и аналитиков. Трудно будет в такой обстановке не сойти с ума.

Если так делать по всем правилам я подозреваю что на канбан доске будут сотня задач, 7 колонок и человек 15-20 девов и аналитиков. Трудно будет в такой обстановке не сойти с ума.

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

ну и выделение типов задач цветом тоже помогает

Ок давай удачи :) Но пасха завтра

у нас тут уже пасха

Уже доставилась на прод? Ну тогда Христос воскресе

А мы все еще деплоим

Воистину воскресе

дак вот

я тут почитал, что вы писали

бизнос в любом случае хочет, чтобы вы деплоили как можно чаще

просто при этом страшно, что вы можете что-нибудь по дороге взорвать

поэтому бизнес терпит, что вы деплоитесь редко