Наверное ваши конкуренты

в чем разница

Это ты мне расскажи :)

не, не это

не ты

даже не слышал про них)
скорее : хантфлоу , какой-то там стафф и что-то еще

вай, нашёл

хантфоу удобная штука, у нас ее выбрали

ну она и дешевле в разы :) у нас модулей больше и интеграции..
но и продукт для крупных компаний..

не для нищуков

ну это грубо звучит)

слишком много всего чего не нужно с большей ценой, потребности у всех разные

ну у нас конструктор модулей для клиентов) можно выбрать чего надо, от этого и ценообразование зависит

ну это я знаю. все эти зибели, сапы и сейлсфорсы "мор зен црм". но в целом там фокуса на hr вроде нет. ну или я не в курсе

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

использовать контрактные тесты при разработке, к тому же мокать бек енд…как по мне идея очень плохая.
1. кучу времени потратить необходимо, чтобы насоздавать эти моки (да и контрактные тесты не про моки). По сути необходимо построить тестовый бек энд…
2. слишком большой охват функционала. Бекенд это обычно не один сервис. А значит запланированные и сделанные моки придут в негодность в тот момент, когда хороший ПО придет к команде и скажет, что на рынке ситуация изменилась, и чтобы быть конкурентноспособным, нам надо добавить фукнционал, а часть урезать, чтобы успеть все выкатить к сроку. Т.е. как только закончишь писать моки для бекенда, он почти сразу перестанет быть актуальным в современных реалиях и когда везде пруд пруди эджайл и прочая хрень.
3. ответственность - когда есть один сервис, то обычно можно найти команду которая будет отвечать за него, а когда у вас бекенд..то нужно держать минимум 2 людей, которые просто идеально знают техническую часть всего бекенда, хорошо разбираются в бизнесе, чтобы понимать что нужно включить в контрактные тесты а что нет ну и быть автоматизатором или программистом. Если разбивать все это на разные роли, то получится, что нужна целая команда, которая будет только и заниматься контрактными тестами, а это дорого. А найти двух людей, которые все это будут уметь делать нереально и скорее всего они тоже будут недешевыми и ко всему прочему возникает огромный риск для компании т.к. если уйдут эти двое, то разработка-релиз продукта будет под угрозой

т.е. контрактные тесты, это больше про то, чтобы не сломать существующий функционал, а не про то, чтобы разработать новый.

Был похожий опыт на первом проекте

private static bool alreadyInitialized = false;

@BeforeAll
public static initialize () {
 if (alreadyInitialized) {return;}
 ...magic here...
}

Спасибо, это очень ценно.

Нас опять хотят озолотить! @Archieru