фича-флаги — тема для отдельной статьи, и в общем никто не спорит, что их можно подружить с гитфлоу. здесь же мы хотели сказать, что при прочих равных с TBD такие процессы выстроить проще, поскольку сам подход ориентирует на выпуск продукта микрорелизами
согласны, мы неточно выразились в тексте — такой вариант отчасти подразумевается в п.2: "разделение между арендаторами происходит на уровне инфраструктуры. Каждая группа пользователей заходит на свой URL или подключается к собственному серверу".
что касается проблем с бизнес-логикой, то они сильно сокращаются, если мультитенантность приложения закладывается изначально, на уровне архитектуры. если на эти рельсы переводить уже работающий продукт, то, да, код придётся изрядно перерыть
На самом деле не столь важно, какой из систем будет собираться конечный фреймворк.
Важно скорее то, как его подключать в качестве зависимости.
Если остановить свой выбор на Carthage, то можно воспользоваться поддержкой уже собранных зависимостей (Binary only frameworks), которые подтягиваются на основе файлов-спецификаций в формате JSON. Версионирование таких зависимостей немного отличается от работы с зависимостями, собираемыми из исходного кода, где конкретная версия библиотеки обозначается через релизный тэг в git. Разница в том, что версии зависимостей для Binary only frameworks определяются в файле-спецификации, а не на основе списка тэгов git.
Таким образом, для поддержки этой фичи Carthage при сборке библиотек на CI/CD системе, потребуется хранить и обновлять файл-спецификацию со списком собранных артефактов и ссылками на них.
Что касается хранения зависимостей в репозитории, тут возможны различные варианты.
Если делать этого не хочется, то можно оставить подтягивание зависимостей на совести Carthage на этапе сборки проекта. При этом, если хочется — не обязательно включать папку с подтянутыми зависимости в репозирий, читай включить её в .gitignore. Просто при каждой сборке проекта будет выполняться дополнительная операция по стягиванию/синхронизации зависимостей.
У нас в базе тоже хранятся разные типы данных, просто мы приводим их к нужному виду для отображения. Если же вы спрашиваете про разные типы ячеек, то у нас для этого были сделаны специальные методы. Они для каждого QuestionnaireCellType возвращали его contentType, который отвечал за вид ячейки. А уже для каждой ячейки строится своя viewModel.
Все viewModel ячеек подписаны на один протокол, чтобы его можно было передавать в любую ячейку. И уже ячейка будет определять, подходит ли ей эта viewModel или нет.
А что именно он выкладывает в релизную ветку? релизная ветка имеет название версии вашего продукта?
Релиз :)
Изменения собираются в очередную RC ветку, которая проходит все необходимые предрелизные процедуры и потом эта ветка мержится в релизную ветку.
Сколько у вас компонентов?
На данный момент около 20
То есть при каждом релизе вы деплоите (удаляете и снова создаете) все докер образы в кубере?
Docker-образы в кубернетисе мы не удаляем, но да, всё приложение разворачивается из новых версий docker-образов.
Аффектит ли ошибка в компоненте системы на другие системы? Я так понимаю другие разработчики ждут пока все у кого ошибка в тестах их не исправят. Верно? Хотя наверное у вас Feature branch и ошибки исправляются в тестах в Feature branch.
У нас разработка в feature-ветках, и на Merge Request обязательно запускается билд с прогоном всех тестов, так что ошибки изолируются.
Какая версия Java? Какой вендор Java вы используете? Какой средний размер образа docker?
На самом деле, по умолчанию git describe выдает хэш последнего комита именно из семи символов. Но мы решили это проставить явно, чтобы не зависеть от возможного изменения дефолтного поведения команды.
Сначала вы синхронизируетесь с Git-репозиторием заказчика, а потом вы развертываете в тесте? Сначала обычно тестируют в тесте, а потом отправляют изменения заказчику.
Это среда UAT — User Acceptance Testing. То есть та среда, где конечные бизнес-пользователи или владельцы продукта могли проверить главные бизнес-фичи.
Как вы справляетесь с проблемами helm?
habr.com/ru/company/southbridge/blog/429340
habr.com/ru/company/flant/blog/438814
С какими именно? В этих статьях довольно большой обзор разных проблем.
Мы работаем с SOAP запросами, нам приходится парсить и модифицировать XML запросы, а Kong, согласно этой информации, не умеет с ними работать.
В сторону Ocelot и Tyk не смотрели, поскольку с нашим набором условий (API-портал с зарегистрированными пользователями и огромная экосистема, построенная вокруг портала) показалось проще и надежнее сделать свой API Gateway. Вы их использовали? Поделитесь опытом?
В документе неплохо отобразить критерии по котором тестировщик будет выставлять Severity дефекту, от проекта к проекту они могут меняться. Полезно команде тестирования иметь один подход к определению важности и на случай ротаций пригодится.
Полностью согласны. Мы написали про приотритеты тестирования во второй главе, кажется, это соотносится с вашим тезисом.
Стратегия тестирования = тест-план в вашем подходе?
Согласны, кардинальной разницы нет. Мы описываем подход к тестированию на конкретном проекте, нам удобнее называть это стратегией.
Многостраничный документ с подробным описанием подходов, методов и техник точно поможет в этом? Есть подозрение, что условный Вася-разработчик на документ и не посмотрит.
Наш опыт показывает, что документ получается не такой уж и большой. Например, составленный документ на одном текущем проекте — всего 3 листа. Для разработчиков важны задачи, а они как раз берутся из стратегии.
Если тестировщик делает что-то не связанное с тестированием, зачем это отражать в документе про тестирование? В списке для примера обычные задачи тестировщика, по крайней мере из моего опыта. Для молодых PM-ов, которые впервые столкнулись с тестированием список будет полезен. Для остальных — наверное, нет.
Наш опыт показывает, что не всем это бывает столь же очевидно, поэтому лучше свериться и знать точно, чего PM ждёт от тестировщика на проекте.
Такой документ обязательно должен давать ответ на то, какие ошибки мы считаем важными, какие — нет. Какие необходимо чинить ASAP, а на какие можно забить. Отсылка в критериях готовности к этому в статье есть.
KPI мы используем не для того, чтобы отследить, работает или нет. Функциональность может работать, но ей никто не будет пользоваться. И осмысленные KPI помогают такие ситуации отловить.
Конфигурация ПО на них определяется динамически (например есть файл описания среды в ветке), или есть статический файл конфигурации, который обновляется по мере необходимости?
Вся конфигурация находится в гите. При деплойменте выгружаем на сервера. Разработчик, выполняющий задачу, отвечает за то, чтобы в настройках всех окружений стояли правильные настройки, которые он добавляет или меняет.
"Нет, уже перешли, теперь настала стадия «А правильно ли все сделано? может есть более лучший способ, практики?»"
Мы на нескольких проектах используем Gitlab CI и с контейнерами, и без. То есть опыт у нас довольно обширный. Но без предмета обуждения сложно сказать. Если приведете пример вашего файла, то сможем прокомментировать.
Сейчас ждем новую версию Gitlab CE, в которой будет доступна возможность разделить .gitlab-ci.yml на несколько файлов.
Мы все запускаем ранером. Он деплоит, ждет, чтобы все запустилось, выполняет тесты и т.д.
Используете контейнеры (чем оркестрируете) или отдельные виртуальные сервера?
Используем отдельные виртуальные севера.
Есть ли что то интересное в действиях ранеров?
Уточните ваш вопрос, пожалуйста. Вы рассматриваете возможность перехода на Gitlab CI, и вам нужно понять стоит это делать или нет?
Как именно тестировщики идут в ветку для воспроизведения ошибок?
Тестировщики не "ходят" в ветку. Руками тестируется магистральная ветка, созданая специально для этих целей с очевидным названием QA. Мы руками не тестируем каждый фича бранч отдельно.
фича-флаги — тема для отдельной статьи, и в общем никто не спорит, что их можно подружить с гитфлоу. здесь же мы хотели сказать, что при прочих равных с TBD такие процессы выстроить проще, поскольку сам подход ориентирует на выпуск продукта микрорелизами
согласны, мы неточно выразились в тексте — такой вариант отчасти подразумевается в п.2: "разделение между арендаторами происходит на уровне инфраструктуры. Каждая группа пользователей заходит на свой URL или подключается к собственному серверу".
что касается проблем с бизнес-логикой, то они сильно сокращаются, если мультитенантность приложения закладывается изначально, на уровне архитектуры. если на эти рельсы переводить уже работающий продукт, то, да, код придётся изрядно перерыть
пожалуйста)
На самом деле не столь важно, какой из систем будет собираться конечный фреймворк.
Важно скорее то, как его подключать в качестве зависимости.
Если остановить свой выбор на Carthage, то можно воспользоваться поддержкой уже собранных зависимостей (Binary only frameworks), которые подтягиваются на основе файлов-спецификаций в формате JSON. Версионирование таких зависимостей немного отличается от работы с зависимостями, собираемыми из исходного кода, где конкретная версия библиотеки обозначается через релизный тэг в git. Разница в том, что версии зависимостей для Binary only frameworks определяются в файле-спецификации, а не на основе списка тэгов git.
Таким образом, для поддержки этой фичи Carthage при сборке библиотек на CI/CD системе, потребуется хранить и обновлять файл-спецификацию со списком собранных артефактов и ссылками на них.
Что касается хранения зависимостей в репозитории, тут возможны различные варианты.
Если делать этого не хочется, то можно оставить подтягивание зависимостей на совести Carthage на этапе сборки проекта. При этом, если хочется — не обязательно включать папку с подтянутыми зависимости в репозирий, читай включить её в .gitignore. Просто при каждой сборке проекта будет выполняться дополнительная операция по стягиванию/синхронизации зависимостей.
С большой вероятностью сделаем, спасибо!
Поскольку свою среду мы считаем доверенной, вопросы безопасности глубоко не рассматривали. Это хорошая мысль, чтобы немного доработать наш подход.
У нас в базе тоже хранятся разные типы данных, просто мы приводим их к нужному виду для отображения. Если же вы спрашиваете про разные типы ячеек, то у нас для этого были сделаны специальные методы. Они для каждого QuestionnaireCellType возвращали его contentType, который отвечал за вид ячейки. А уже для каждой ячейки строится своя viewModel.
Все viewModel ячеек подписаны на один протокол, чтобы его можно было передавать в любую ячейку. И уже ячейка будет определять, подходит ли ей эта viewModel или нет.
Спасибо за отклик! Рады, что наш опыт вам полезен
Релиз :)
Изменения собираются в очередную RC ветку, которая проходит все необходимые предрелизные процедуры и потом эта ветка мержится в релизную ветку.
На данный момент около 20
Docker-образы в кубернетисе мы не удаляем, но да, всё приложение разворачивается из новых версий docker-образов.
У нас разработка в feature-ветках, и на Merge Request обязательно запускается билд с прогоном всех тестов, так что ошибки изолируются.
OpenJDK 8
На самом деле, по умолчанию git describe выдает хэш последнего комита именно из семи символов. Но мы решили это проставить явно, чтобы не зависеть от возможного изменения дефолтного поведения команды.
Это среда UAT — User Acceptance Testing. То есть та среда, где конечные бизнес-пользователи или владельцы продукта могли проверить главные бизнес-фичи.
С какими именно? В этих статьях довольно большой обзор разных проблем.
Да
Мы не храним ничего в контейнерах, все микросервисы у нас stateless.
Вы могли бы уточнить, каких подробностей не хватило в статье?
Как бы странно это ни звучало, но такое демо действительно было (слайд "OKMP: результаты")
Летом записи появятся на YouTube-канале конференции
Мы работаем с SOAP запросами, нам приходится парсить и модифицировать XML запросы, а Kong, согласно этой информации, не умеет с ними работать.
В сторону Ocelot и Tyk не смотрели, поскольку с нашим набором условий (API-портал с зарегистрированными пользователями и огромная экосистема, построенная вокруг портала) показалось проще и надежнее сделать свой API Gateway. Вы их использовали? Поделитесь опытом?
Организаторы конференции говорят в комментариях, что весной доклады появятся в публичном доступе, и можно будет посмотреть всё в онлайне.
Дополним предыдущий ответ.
Да, вы совершенно правы, смысл в итеративности.
Полностью согласны. Мы написали про приотритеты тестирования во второй главе, кажется, это соотносится с вашим тезисом.
Согласны, кардинальной разницы нет. Мы описываем подход к тестированию на конкретном проекте, нам удобнее называть это стратегией.
Наш опыт показывает, что документ получается не такой уж и большой. Например, составленный документ на одном текущем проекте — всего 3 листа. Для разработчиков важны задачи, а они как раз берутся из стратегии.
Наш опыт показывает, что не всем это бывает столь же очевидно, поэтому лучше свериться и знать точно, чего PM ждёт от тестировщика на проекте.
KPI мы используем не для того, чтобы отследить, работает или нет. Функциональность может работать, но ей никто не будет пользоваться. И осмысленные KPI помогают такие ситуации отловить.
Вся конфигурация находится в гите. При деплойменте выгружаем на сервера. Разработчик, выполняющий задачу, отвечает за то, чтобы в настройках всех окружений стояли правильные настройки, которые он добавляет или меняет.
Мы на нескольких проектах используем Gitlab CI и с контейнерами, и без. То есть опыт у нас довольно обширный. Но без предмета обуждения сложно сказать. Если приведете пример вашего файла, то сможем прокомментировать.
Сейчас ждем новую версию Gitlab CE, в которой будет доступна возможность разделить .gitlab-ci.yml на несколько файлов.
Мы все запускаем ранером. Он деплоит, ждет, чтобы все запустилось, выполняет тесты и т.д.
Это люди, которые осуществляют приемку. В нашем случае — технологи заказчика.
Используем отдельные виртуальные севера.
Уточните ваш вопрос, пожалуйста. Вы рассматриваете возможность перехода на Gitlab CI, и вам нужно понять стоит это делать или нет?
Тестировщики не "ходят" в ветку. Руками тестируется магистральная ветка, созданая специально для этих целей с очевидным названием QA. Мы руками не тестируем каждый фича бранч отдельно.