Comments 32
Мне вот интересно 2 момента:
- Сколько у вас агентов? Бесплатны ведь три, а дальше ТС начинает стоить как космолёт.
- Почему ТС? Наверняка ведь в Яндексе есть своя самостоятельная система сборки, да ещё и бесплатная. Это наверняка в силу п.1 позволило бы сэкономить массу денег.
Я не от имени Яндекса говорю, но если уж одна из самых крупных российских контор себе не сможет позволить купить лицензию, то кто тогда? А несколько я знаю в целом продукт достаточно популярен в России.
Насчет Яндекса — они тоже деньги считают. Я понимаю, что есть разные кейсы, но вот, например, с оракла они переехали на постгрес. Даже при учете того, что постгрес потребовал х3 железа — все равно получилось дешевле.
Постгрес действительно потребовал в 3 раза больше железа? Это в случае яндекса или средняя разница по потребляемым ресурсам?
Речь не про облако, а про это: https://m.habr.com/ru/post/321756/
Агентов ~100 штук только в такси. На мобильную команду хватает 10 агентов.
Стоимость ТС не такая уж большая, если пересчитать трудозатраты на реализацию и поддержку своей системы.
Почему ТС? Так исторически сложилось. Это означает багаж уже написанного кода и инфраструктуры, который нельзя просто так взять и дропнуть :) Это и плагины, и бэкенд сервисы (аналитика, мониторинги, интеграции). Слишком золотой вышел бы переезд на новую систему. Плюс, оперативный саппорт из коробки :)
Стоимость ТС не такая уж большая, если пересчитать трудозатраты на реализацию и поддержку своей системы.
Почему ТС? Так исторически сложилось. Это означает багаж уже написанного кода и инфраструктуры, который нельзя просто так взять и дропнуть :) Это и плагины, и бэкенд сервисы (аналитика, мониторинги, интеграции). Слишком золотой вышел бы переезд на новую систему. Плюс, оперативный саппорт из коробки :)
Спасибо. Т.е. я правильно понял, что
- В Яндексе есть своя система сборки проектов?
- Решение использовать тимсити — локально для проекта Яндекс.Такси ?
- Миграция на общую систему сборки — дорогое удовольствие, т.к. надо переписывать процессы и пока дешевле платить за лицензии ТС и за железо под него?
1. Есть и своя, и ТС.
2. В Такси все проекты всегда жили в ТС.
3. На текущий момент это так) Да и железа ТС ест мало — две средне-упитанные серверные ноды + виртуалки для билд-агентов.
И называть ТС системой сборки не совсем корректно (да, я зануда) — это сервис для непрерывной сборки :) Система сборки у каждого проекта осталась неизменной.
2. В Такси все проекты всегда жили в ТС.
3. На текущий момент это так) Да и железа ТС ест мало — две средне-упитанные серверные ноды + виртуалки для билд-агентов.
И называть ТС системой сборки не совсем корректно (да, я зануда) — это сервис для непрерывной сборки :) Система сборки у каждого проекта осталась неизменной.
На картинке RAID-10 вроде как ещё работоспособный.
Про версионирование настроек и security не знал. Спасибо за наводку!
Про версионирование настроек и security не знал. Спасибо за наводку!
На картинке RAID-10 вроде как ещё работоспособный.
Картинка модельная (из какой-нибудь презенташки по RAID 1+0), вряд ли именно так развалилась полка дисков.
Да и на их месте (раз они в Яндекс.Облаке поддерживают хранилище с API Amazon S3), я бы вместо выделенного хранилища всё хранение артефактов на S3 перенёс, благо, официальный плагин для teamcity давно есть.
офтоп: включать опцию "5% чаевых" без предупреждения (!) при добавлении карты и моментальной последующей оплаты долга за предыдущую поездку такой себе маркетинговый ход...
Это не маркетинговый ход, а просто отсутствие проработки всех возможных сценариев.
И, да, мне всегда в этих случаях техподдержка рассказывает байки (что Я.Т, что Ситимобила), что нужно держать подключенную к такси карту, так ещё и с положительным балансом (WAT!?)
Давайка лучше на пикабу со своими оффтопиком. Тут достаточно интересный доклад, а не место жалоб на яндекс такси.
Здравствуйте! Я из поддержки Яндекс.Такси. При привязке карты должно было появиться дополнительное окно, где можно выбрать размер чаевых по умолчанию. Напишите, пожалуйста, нам на почту blogs@taxi.yandex.ru — проверим, почему этого не произошло.
Немного не в топик, но пользуясь случаем расскажу.
На днях в мою стоячую машину «приехал» Яндекс.Такси (ЯТ) — не сильно, но обидно. Очень долго общались за ущерб. Из-за чего я опоздал на работу. Профакапил ряд тасков. Получил по башке от начальника. Перенервничал. Задержался на работе. В целом, негативный осадок от компании остался, т.к.:
а) нет входного теста на адекватность водил — берут кого попало.
б) нет телефона на бортах машины, куда можно обратиться в случае небрежного вождения водилы, чтобы его штрафанули хорошенько. А вообще ЯТ хоть в курсе как его водилы разъезжают или только денежку стрегут, а всё остальное «возле птицы»?
в) нет компенсационной политики со стороны ЯТ пострадавшей стороне.
г) возможно еще много чего, но к счастью пассажиром ЯТ пока не приходилось быть.
На днях в мою стоячую машину «приехал» Яндекс.Такси (ЯТ) — не сильно, но обидно. Очень долго общались за ущерб. Из-за чего я опоздал на работу. Профакапил ряд тасков. Получил по башке от начальника. Перенервничал. Задержался на работе. В целом, негативный осадок от компании остался, т.к.:
а) нет входного теста на адекватность водил — берут кого попало.
б) нет телефона на бортах машины, куда можно обратиться в случае небрежного вождения водилы, чтобы его штрафанули хорошенько. А вообще ЯТ хоть в курсе как его водилы разъезжают или только денежку стрегут, а всё остальное «возле птицы»?
в) нет компенсационной политики со стороны ЯТ пострадавшей стороне.
г) возможно еще много чего, но к счастью пассажиром ЯТ пока не приходилось быть.
А причем тут Яндекс? С тем же успехом мог приехать любой другой таксист.
Или не знаю… Любой небрежный офисный хомячок.
А в нас однажды вообще бензовоз приехал. Теперь все НПЗ клеймить, что ли ?
нет входного теста на адекватность водил — берут кого попало.
Насколько я понимаю, там достаточно хитрая система. Когда есть водители, которые напрямую с Я.Т работают, а есть партнёры. И есть подозрение, что предрейсовый контроль у партнёров как раз… Отсутствует. И вроде бы была опция в программе, которая позволяет отключить небрендированные машины и/или партнёров, или я с другой службой такси путаю ?
Яндекс тут именно при том, что это его неадекватный сотрудник приехал в меня, а не 3rd-party хомячок. По поводу партнёров вы правы. Скорее всего в моем городе какая-либо юр.структура от ЯТ отсутствует, а вместо него есть всякие однодневки типа Ашот-транспортэйшн или Дамшут-такси, отсюда и контроль соотвествующий. Но внимание — машины брендованные в стиле Яндекса! В любом случае — написать телефон для жалоб и организовать отдел в ЯТ по работе с жалобами считаю просто необходимым, т.к. ДТП совершил именно сотрудник ЯТа, и не важно сколько там фирм-прослоек от Яндекса до самого водилы — это его человек и его ответственность. Ведь основную прибыль гребёт именно ЯТ, не так ли? А следовательно и основная ответственность за подобные инциденты должна быть его.
UUID на самом деле необязателен. Если UUID не задать, то он генерируется из обычного id, который получается из имени объекта.
Другое дело, что иногда может придти мысль «порефакторить» конфигурации и переименовать объект. А так как истолия сборок связана через этот id, то при переименовании объекта история вдруг может оказаться несвязанной с новом id. Но этого можно избежать — либо задать таки UUID, либо связать историю через UI.
Другое дело, что иногда может придти мысль «порефакторить» конфигурации и переименовать объект. А так как истолия сборок связана через этот id, то при переименовании объекта история вдруг может оказаться несвязанной с новом id. Но этого можно избежать — либо задать таки UUID, либо связать историю через UI.
Почитал доку про версионирование настроек. Правильно ли я понял, что любые изменения, сделанные в gui, придётся вручную вносить через патч, который TC сохранит в репе настроек? Выглядит не совсем удобным.
У нас один из шагов сборки сохраняет новое значение в переменную проекта (в ней хранится вычисляемый определённым образом номер версии приложения), и, соответсвенно, при следующей сборке уже используется это новое значение переменной (чтобы вычислить следующее значение и т.д.). Выглядит это как изменения внесённые через gui, т.е. в gui после сборки отображается новое значение переменной. Сборки запускаются автоматом при пуше в репу проекта.
Хотелось бы, чтобы TC репу настроек, соответственно, автоматом обновлял, при внесении изменений в gui. Т.к. в нашем случае вручную отслеживать поступление патчей сложно.
Понятно, что можно добавить ещё один степ сборки и накатывать автоматом этот патч. Но, во-первых, выглядит костыльно, а, во-вторых, пока не понятно, когда этот патч появляется в репе конфига.
Можете как-то прокомментировать или подсказать что-нибудь по этому поводу?
У нас один из шагов сборки сохраняет новое значение в переменную проекта (в ней хранится вычисляемый определённым образом номер версии приложения), и, соответсвенно, при следующей сборке уже используется это новое значение переменной (чтобы вычислить следующее значение и т.д.). Выглядит это как изменения внесённые через gui, т.е. в gui после сборки отображается новое значение переменной. Сборки запускаются автоматом при пуше в репу проекта.
Хотелось бы, чтобы TC репу настроек, соответственно, автоматом обновлял, при внесении изменений в gui. Т.к. в нашем случае вручную отслеживать поступление патчей сложно.
Понятно, что можно добавить ещё один степ сборки и накатывать автоматом этот патч. Но, во-первых, выглядит костыльно, а, во-вторых, пока не понятно, когда этот патч появляется в репе конфига.
Можете как-то прокомментировать или подсказать что-нибудь по этому поводу?
Распишу по-порядку.
* ТС создаёт патч на любое изменение из UI. Можно запретить вносить изменения из UI и тогда придётся всё делать через пулл реквесты в репозиторий с настройками.
* Применять или не применять патч — дело личное, но со временем кучка патчей превратится в свалку и разобрать их будет сложно. Поэтому лучше не допускать этого. Либо, см. пункт выше :)
* Изменение переменной проекта при сборке — моветон, лучше избегать подобных манипуляций. Храните переменную в гите вместе с проектом (можно ведь сделать коммит/пуш прямо с билд-агента от лица какого-нибудь сервисного пользователя), либо в удалённой БД. Если уж очень-очень надо — напишите простенький плагин для ТС и делайте это через механизм property-file. Есть подобный плагин — autoincrement. Если по-простому — он позволяет определить монотонно-возрастающую числовую переменную для нескольких билд-конфигураций и/или проектов.
* Отдельным степом сборки применять патчи не кошерно, но может помочь на больших проектах справиться с патч-штормом. Лучше избегать таких подходов, по возможности)
* ТС создаёт патч на любое изменение из UI. Можно запретить вносить изменения из UI и тогда придётся всё делать через пулл реквесты в репозиторий с настройками.
* Применять или не применять патч — дело личное, но со временем кучка патчей превратится в свалку и разобрать их будет сложно. Поэтому лучше не допускать этого. Либо, см. пункт выше :)
* Изменение переменной проекта при сборке — моветон, лучше избегать подобных манипуляций. Храните переменную в гите вместе с проектом (можно ведь сделать коммит/пуш прямо с билд-агента от лица какого-нибудь сервисного пользователя), либо в удалённой БД. Если уж очень-очень надо — напишите простенький плагин для ТС и делайте это через механизм property-file. Есть подобный плагин — autoincrement. Если по-простому — он позволяет определить монотонно-возрастающую числовую переменную для нескольких билд-конфигураций и/или проектов.
* Отдельным степом сборки применять патчи не кошерно, но может помочь на больших проектах справиться с патч-штормом. Лучше избегать таких подходов, по возможности)
Спасибо за комментарии!
Глянул, TC патчи тоже версионирует. Т.е. появилось по одному патчу на настроенную сборку (где были изменения конфига), которые перезаписываются и коммитется. Если не важна история изменения конфига (а в случае, когда изменяется только одна переменная проекта TC, она наверное, не важна), можно и руками периодически применять текущие патчи.
На самом деле, у нас так и есть — переменная с версией приложения хранится в гите (правда, в отдельном проекте). Но также есть зеркальная ей переменная проекта в TC. Разработчику удобно видеть в gui TC текущую версию приложения. Плюс, переменная нужна для плагина, который в Слаку отправляет сообщения, а этот плагин оперирует только переменными проекта TC. От плагина можно отказаться, т.к. в Слаку легко слать сообщения и без плагина. Наверное, можно, пожертвовав удобством разработчиков, вообще отказаться от этой переменной проекта в TC. Тогда и патчей, связанных с изменениями этой переменной, не будет.
Да, согласен, надо не патч применять степом сборки, а сам конфиг изменять. Мне кажется, если одним степом изменить конфиг (значение переменной проекта TC), а следующим — саму переменную проекта TC, то патча не будет, т.к переменная будет соответствовать конфигу. Надо проверить.
Глянул, TC патчи тоже версионирует. Т.е. появилось по одному патчу на настроенную сборку (где были изменения конфига), которые перезаписываются и коммитется. Если не важна история изменения конфига (а в случае, когда изменяется только одна переменная проекта TC, она наверное, не важна), можно и руками периодически применять текущие патчи.
На самом деле, у нас так и есть — переменная с версией приложения хранится в гите (правда, в отдельном проекте). Но также есть зеркальная ей переменная проекта в TC. Разработчику удобно видеть в gui TC текущую версию приложения. Плюс, переменная нужна для плагина, который в Слаку отправляет сообщения, а этот плагин оперирует только переменными проекта TC. От плагина можно отказаться, т.к. в Слаку легко слать сообщения и без плагина. Наверное, можно, пожертвовав удобством разработчиков, вообще отказаться от этой переменной проекта в TC. Тогда и патчей, связанных с изменениями этой переменной, не будет.
Да, согласен, надо не патч применять степом сборки, а сам конфиг изменять. Мне кажется, если одним степом изменить конфиг (значение переменной проекта TC), а следующим — саму переменную проекта TC, то патча не будет, т.к переменная будет соответствовать конфигу. Надо проверить.
Можно оставить переменную в ТС, только сделать её по-другому :) Я выше показал на примере плагина автоинкремента, как это делается. Условно, при каждой сборке некая переменная пробрасывается прямо в файлик на ФС сервера (средствами плагина). Таким образом, никаких изменений в конфигах проекта не происходит, а значение переменной обновляется на каждом билде.
Автоматически применить патч можно только переписав полностью настройки. Ведь в коде могут быть заведены какие-нибудь свои абстракции про которые ТС не знает. ТС работает с внутренней моделью проекта и патч генерируется относительно этой модели.
Sign up to leave a comment.
Рецепты TeamCity. Доклад Яндекс.Такси