При создании репозитория Тимсити предложит экспортировать текущее дерево проектов в xml/kotlin конфиги. И там уже uuid каждого объекта будут.
Если пишите свой конфиг с нуля — можно просто создать самому любым удобным способом этот идентификатор. Я использую *nix команду в терминале — uuidgen.
Можно оставить переменную в ТС, только сделать её по-другому :) Я выше показал на примере плагина автоинкремента, как это делается. Условно, при каждой сборке некая переменная пробрасывается прямо в файлик на ФС сервера (средствами плагина). Таким образом, никаких изменений в конфигах проекта не происходит, а значение переменной обновляется на каждом билде.
* ТС создаёт патч на любое изменение из UI. Можно запретить вносить изменения из UI и тогда придётся всё делать через пулл реквесты в репозиторий с настройками.
* Применять или не применять патч — дело личное, но со временем кучка патчей превратится в свалку и разобрать их будет сложно. Поэтому лучше не допускать этого. Либо, см. пункт выше :)
* Изменение переменной проекта при сборке — моветон, лучше избегать подобных манипуляций. Храните переменную в гите вместе с проектом (можно ведь сделать коммит/пуш прямо с билд-агента от лица какого-нибудь сервисного пользователя), либо в удалённой БД. Если уж очень-очень надо — напишите простенький плагин для ТС и делайте это через механизм property-file. Есть подобный плагин — autoincrement. Если по-простому — он позволяет определить монотонно-возрастающую числовую переменную для нескольких билд-конфигураций и/или проектов.
* Отдельным степом сборки применять патчи не кошерно, но может помочь на больших проектах справиться с патч-штормом. Лучше избегать таких подходов, по возможности)
Это так. На практике, лучше обязать всегда явно задавать уникальный UUID, в дальнейшем это сильно упростит всем жизнь :) И в плане рефакторинга, и в контексте внесения изменений через UI.
1. Есть и своя, и ТС.
2. В Такси все проекты всегда жили в ТС.
3. На текущий момент это так) Да и железа ТС ест мало — две средне-упитанные серверные ноды + виртуалки для билд-агентов.
И называть ТС системой сборки не совсем корректно (да, я зануда) — это сервис для непрерывной сборки :) Система сборки у каждого проекта осталась неизменной.
Агентов ~100 штук только в такси. На мобильную команду хватает 10 агентов.
Стоимость ТС не такая уж большая, если пересчитать трудозатраты на реализацию и поддержку своей системы.
Почему ТС? Так исторически сложилось. Это означает багаж уже написанного кода и инфраструктуры, который нельзя просто так взять и дропнуть :) Это и плагины, и бэкенд сервисы (аналитика, мониторинги, интеграции). Слишком золотой вышел бы переезд на новую систему. Плюс, оперативный саппорт из коробки :)
На новом сервере именно на S3 и переехали :) Все артефакты принудительно в облако отгружаются, а локальное хранилище чистится каждые 2-3 дня от тонны логов.
А сколько человек на 15 минут? И есть ли модератор?
как правило в таких митингах участвует ~5 человек, один из которых следит за проведением самого митинга
Если все сидят рядом в опенофисе, то хочешь не хочешь, знаешь и видишь что происходит вокруг.
Вы абсолютно правы, но при этом объявление какого-то значимого рефакторинга или тормозящей проблемы на стендапе 'гарантирует' что эта информация дойдет до каждого члена команды
это достаточно частое явление, ведь у всех разработчиков разный опыт и разный путь в IT-индустрии — кто-то мог на предыдущем месте работы столкнуться с точно такой же проблемой, кто-то мог работать с той же СУБД но не касаться описанного случая, а кто-то мог работать с абсолютно другим стеком технологий, поэтому обсуждение (или хотя бы упоминание проблемы) только приветствуется на скрамах
спасибо за вопрос, верно подмечено, у нас в команде есть ограничение в 15 минут на скрам-митинг, в рамках встречи обязательно регулируется время, затраченное на поднятый вопрос и часто его обсуждение откладывается на время после скрама (особенно если это какой-то технически сложный вопрос, например требующий погружения в архитектуру сервиса)
но также скрам-встреча позволяет акцентировать внимание на отдельных моментах проделанной работы (как например вопрос связанный с sql скриптом), если бы вопрос не был поднят — Анна бы и не узнала, что у Вадима есть экспертиза в данном вопросе и скорее всего потратила намного больше времени на раскопки
да, иногда используются маркерные доски (в офисе достаточно мест, где можно пописать маркером), но обычно какие-то визуальные или архитектурные вопросы откладываются на обсуждения после скрам-митинга
Если пишите свой конфиг с нуля — можно просто создать самому любым удобным способом этот идентификатор. Я использую *nix команду в терминале — uuidgen.
* ТС создаёт патч на любое изменение из UI. Можно запретить вносить изменения из UI и тогда придётся всё делать через пулл реквесты в репозиторий с настройками.
* Применять или не применять патч — дело личное, но со временем кучка патчей превратится в свалку и разобрать их будет сложно. Поэтому лучше не допускать этого. Либо, см. пункт выше :)
* Изменение переменной проекта при сборке — моветон, лучше избегать подобных манипуляций. Храните переменную в гите вместе с проектом (можно ведь сделать коммит/пуш прямо с билд-агента от лица какого-нибудь сервисного пользователя), либо в удалённой БД. Если уж очень-очень надо — напишите простенький плагин для ТС и делайте это через механизм property-file. Есть подобный плагин — autoincrement. Если по-простому — он позволяет определить монотонно-возрастающую числовую переменную для нескольких билд-конфигураций и/или проектов.
* Отдельным степом сборки применять патчи не кошерно, но может помочь на больших проектах справиться с патч-штормом. Лучше избегать таких подходов, по возможности)
2. В Такси все проекты всегда жили в ТС.
3. На текущий момент это так) Да и железа ТС ест мало — две средне-упитанные серверные ноды + виртуалки для билд-агентов.
И называть ТС системой сборки не совсем корректно (да, я зануда) — это сервис для непрерывной сборки :) Система сборки у каждого проекта осталась неизменной.
Стоимость ТС не такая уж большая, если пересчитать трудозатраты на реализацию и поддержку своей системы.
Почему ТС? Так исторически сложилось. Это означает багаж уже написанного кода и инфраструктуры, который нельзя просто так взять и дропнуть :) Это и плагины, и бэкенд сервисы (аналитика, мониторинги, интеграции). Слишком золотой вышел бы переезд на новую систему. Плюс, оперативный саппорт из коробки :)
в большинстве случаев задачи обсуждаются на митингах в общих чертах, и лишь в редких случаях задачи разбираются подробно
в примере статьи есть подробные описания задач, их решения, а также итоги по задачам лишь по той простой причине, что читатели находятся вне контекста
как правило в таких митингах участвует ~5 человек, один из которых следит за проведением самого митинга
Вы абсолютно правы, но при этом объявление какого-то значимого рефакторинга или тормозящей проблемы на стендапе 'гарантирует' что эта информация дойдет до каждого члена команды
но также скрам-встреча позволяет акцентировать внимание на отдельных моментах проделанной работы (как например вопрос связанный с sql скриптом), если бы вопрос не был поднят — Анна бы и не узнала, что у Вадима есть экспертиза в данном вопросе и скорее всего потратила намного больше времени на раскопки