Ого, да я раза три кончил, пока это листал! Куча наглых вопросов:
0. Workflow продукта выглядит весьма зрелым (хотя, конечно, и у новых продуктов такое может быть). Как давно развивается продукт, хотя бы примерно? Много ли драйверов изменений workflow: это один человек, пара-тройка, или вся команда? Насколько велик твой собственный вклад?
1. "Цепочки производства" - это реальные pipeline-ы сборки, или просто один pipeline, в котором пропускаются какие-то шаги в зависимости от сложности и типа задач?
2. Вся эта система живёт в одном репозитории кода, или используется несколько разных репозиториев? Разные цвета компонентов - это разные репозитории? Если репозитории разные, часто ли возникают проблемы с синхронизацией изменений между ними?
3. Функциональный макет - интересная тема. Он родился до самого проекта или был создан позже?
4. "EDI для девочек" - тоже интересная тема. Разделение бизнес-логики и обвязки тоже было изначальным архитектурным решением, или возникло во время развития системы? Как реализован код бизнес-логики: это код на C#, на движке правил (rule engine), что-то третье?
5. На первом слайде написано "12 разработчиков + 4 тестировщика", а дальше указано куда больше ролей. Аналитик, программист, проектировщик, фронтендер - это всё разные люди, или кто-то совмещает эти роли?
5. "Код читают все" - круто, но может быть затратно. Сколько примерно времени уходит в день на чтение кода? Я понимаю, что это существенно зависит от глубины вчитывания, но всё равно интересно.
6. Выкладыванием релиза занимаются сами разработчики? Или этим заняты отдельные люди? Из доклада сложилось ощущение, что используется первый вариант, но мало ли...
7. Разбиение тестов на потоки осуществляется автоматически? Если да, то по каким критериям? Много ли внимания тратится на балансировку?
8. Много ли проблем со стабильностью тестов? Как справляетесь с нестабильными тестами: простой перезапуск, лимит на % сломанных тестов, просмотр результатов тестов + ручное "благословление" билда, ... ?
В общем, было бы интересно узнать подробности, в рамках твоего NDA, конечно.
P.S.: на Slideshare ты до сих пор в йандексе работаешь ;)
1. "Т.е., обходитесь без end-to-end автоматизации конвейера сборки?" Мы с тобой похоже говорим о разном. Надо определять.
6. ИМХО, это взросление - разделение на dev и ops
8. Система в бою работает в режиме высокой нагрузки, а при тестировании - нет. Оттого затыки по кешам и асинхронности. Обратно же дебаг микросервисов это не хухры мухры. Браузер стабилен.
9. Отдельная длинная история.
3. Макет в полный рост и всеми. Очень удобная штука.
0. Продукту около четырех лет, я в нем год. 1. Цепочки это типы задач, по каждому из которых каждый знает, что делать , где искать и кому передать дальше. 2. Реп один. 3. Макет - интересная тема, но не моя. Проектировщики и фронты ее пилят. Появились не так давно для реакта. 4. Бизнес-логика это код на шарпе, выделился около год-два назад, когда программистам надоело писать типовые задачи. 5. Четверть, меньше, около того. Ревью у нас много. У ведущих разрабов ревью больше. 6. От первого переходим ко второму, в процессе. 7. Вообще не разбиваем. Разные типы тестов в разных солюшенах идт в разных потоках. В этом и причина неравномерности времени прохождения. 8. Много. Автоматический перезапуск, ограничение на количество таких перезапусков. Чиним, но страдаем, так как чинить такое тяжело. Сломанных случайно до 10. Перед релизом гоняем локально их.
А я через фейсбук логинился, а там я актуальность не поддерживаю.
1. Т.е., обходитесь без end-to-end автоматизации конвейера сборки? Считаете его ненужным, или руки не дошли? Часто ли бывают ошибки, связанные с человеческим фактором (пропуск шага в цепочке и т.п.)?
6. Очень интересно. Почему переходите? Релиз съедает много времени? Слишком сложный? Требуются специфические скиллы? Знаете ли о методологиях, применяемых в DevOps, Continuous Delivery? Вот, кстати, годнота на подумать на эту тему: https://gojko.net/2016/02/01/potentially-shippable/
8. Главный источник нестабильности - браузерота? Или в системных/юнит тестах тоже встречаются такие проблемы? Много ли JS на страницах, тестируется ли фронт отдельно от бэкенда?
9! Автоматизировали ли каким-нибудь образом сбор и учёт ошибок в тестах и на проде? Мониторинг и контроль метрик, анализ логов, стектрейсов, вся эта вот фигня - этим насколько плотно занимаетесь? Разработчики это делают, или как раз свежесоздаваемые внедренцы?
3. Макет используется только при работе над дизайном (слайд 8)? Или используется ещё разработчиками/тестировщиками (например, для создания тест-кейсов и планирования исследовательского тестирования готового приложения)?
Ого, да я раза три кончил, пока это листал! Куча наглых вопросов:
ОтветитьУдалить0. Workflow продукта выглядит весьма зрелым (хотя, конечно, и у новых продуктов такое может быть). Как давно развивается продукт, хотя бы примерно? Много ли драйверов изменений workflow: это один человек, пара-тройка, или вся команда? Насколько велик твой собственный вклад?
1. "Цепочки производства" - это реальные pipeline-ы сборки, или просто один pipeline, в котором пропускаются какие-то шаги в зависимости от сложности и типа задач?
2. Вся эта система живёт в одном репозитории кода, или используется несколько разных репозиториев? Разные цвета компонентов - это разные репозитории? Если репозитории разные, часто ли возникают проблемы с синхронизацией изменений между ними?
3. Функциональный макет - интересная тема. Он родился до самого проекта или был создан позже?
4. "EDI для девочек" - тоже интересная тема. Разделение бизнес-логики и обвязки тоже было изначальным архитектурным решением, или возникло во время развития системы? Как реализован код бизнес-логики: это код на C#, на движке правил (rule engine), что-то третье?
5. На первом слайде написано "12 разработчиков + 4 тестировщика", а дальше указано куда больше ролей. Аналитик, программист, проектировщик, фронтендер - это всё разные люди, или кто-то совмещает эти роли?
5. "Код читают все" - круто, но может быть затратно. Сколько примерно времени уходит в день на чтение кода? Я понимаю, что это существенно зависит от глубины вчитывания, но всё равно интересно.
6. Выкладыванием релиза занимаются сами разработчики? Или этим заняты отдельные люди? Из доклада сложилось ощущение, что используется первый вариант, но мало ли...
7. Разбиение тестов на потоки осуществляется автоматически? Если да, то по каким критериям? Много ли внимания тратится на балансировку?
8. Много ли проблем со стабильностью тестов? Как справляетесь с нестабильными тестами: простой перезапуск, лимит на % сломанных тестов, просмотр результатов тестов + ручное "благословление" билда, ... ?
В общем, было бы интересно узнать подробности, в рамках твоего NDA, конечно.
P.S.: на Slideshare ты до сих пор в йандексе работаешь ;)
0. Двигателей прогресса в зависимости от погоды на Марсе - от 3 до 7 из 19
Удалить1. "Т.е., обходитесь без end-to-end автоматизации конвейера сборки?"
УдалитьМы с тобой похоже говорим о разном. Надо определять.
6. ИМХО, это взросление - разделение на dev и ops
8. Система в бою работает в режиме высокой нагрузки, а при тестировании - нет. Оттого затыки по кешам и асинхронности. Обратно же дебаг микросервисов это не хухры мухры. Браузер стабилен.
9. Отдельная длинная история.
3. Макет в полный рост и всеми. Очень удобная штука.
0. Продукту около четырех лет, я в нем год.
ОтветитьУдалить1. Цепочки это типы задач, по каждому из которых каждый знает, что делать , где искать и кому передать дальше.
2. Реп один.
3. Макет - интересная тема, но не моя. Проектировщики и фронты ее пилят. Появились не так давно для реакта.
4. Бизнес-логика это код на шарпе, выделился около год-два назад, когда программистам надоело писать типовые задачи.
5. Четверть, меньше, около того. Ревью у нас много. У ведущих разрабов ревью больше.
6. От первого переходим ко второму, в процессе.
7. Вообще не разбиваем. Разные типы тестов в разных солюшенах идт в разных потоках. В этом и причина неравномерности времени прохождения.
8. Много. Автоматический перезапуск, ограничение на количество таких перезапусков. Чиним, но страдаем, так как чинить такое тяжело. Сломанных случайно до 10. Перед релизом гоняем локально их.
А я через фейсбук логинился, а там я актуальность не поддерживаю.
Спасибо большое!
Удалить1. Т.е., обходитесь без end-to-end автоматизации конвейера сборки? Считаете его ненужным, или руки не дошли? Часто ли бывают ошибки, связанные с человеческим фактором (пропуск шага в цепочке и т.п.)?
6. Очень интересно. Почему переходите? Релиз съедает много времени? Слишком сложный? Требуются специфические скиллы? Знаете ли о методологиях, применяемых в DevOps, Continuous Delivery? Вот, кстати, годнота на подумать на эту тему: https://gojko.net/2016/02/01/potentially-shippable/
8. Главный источник нестабильности - браузерота? Или в системных/юнит тестах тоже встречаются такие проблемы? Много ли JS на страницах, тестируется ли фронт отдельно от бэкенда?
9! Автоматизировали ли каким-нибудь образом сбор и учёт ошибок в тестах и на проде? Мониторинг и контроль метрик, анализ логов, стектрейсов, вся эта вот фигня - этим насколько плотно занимаетесь? Разработчики это делают, или как раз свежесоздаваемые внедренцы?
Удалить3. Макет используется только при работе над дизайном (слайд 8)? Или используется ещё разработчиками/тестировщиками (например, для создания тест-кейсов и планирования исследовательского тестирования готового приложения)?
Удалить