7800
правок
Изменения
Новая страница: «Чуть было не пропустил конференцию MS [http://events.techdays.ru/ALM-Summit/2014-02/schedule ALM Summit]. Но накануне ре…»
Чуть было не пропустил конференцию MS [http://events.techdays.ru/ALM-Summit/2014-02/schedule ALM Summit]. Но накануне решил сходить - потому что решение MS по ALM - комплексное и обеспечивает совместную согласованную работу систем поддержки разработки и эксплуатации, и за его развитием интересно следить. И кроме докладов по ALM бонусом получил два интереснейших доклада Александра Рахманова по нагрузочному тестированию и Алексея Лустина про включение 1С-приложений в общий цикл разработки, при котором 1С рассматривается просто как бизнес-ориентированный DSL. Всего было более 400 участников.
Возвращаясь к ALM от MS. К сожалению, ее не удалось полноценно дотянуть до уровня бизнеса и описания архитектуры предприятия (enterprise architecture). В VS Ultimate 2012 такая попытка была, но она по факту не взлетела. А это - важная составляющая при сопровождении ИТ-ландшафта больших предприятий, в которых эксплуатируются десятки приложений, постоянно идут процессы модернизации и внедрения новых приложений и перераспределения между ними бизнес-функций. Но, несмотря на эту лакуну, решение MS по ALM покрывает достаточно большую область задач поддержки разработки приложений и их эксплуатации, и это дает представление и идеи о том, какие функции необходимо реализовывать в системе управления ИТ-ландшафтом, и каким образом их правильно интегрировать, независимо от используемых для этого инструментов.
В частных разговорах - хорошая идея на поле управления IT-ландшафтом была у Jazz (IBM), но она, говорят, провалилась. А вот с линейки HP ALM многие слезают, переходя на ALM от MS. Вообще нарекания на продукты HP я слышал не только на этой конференции.
ALM от MS уже второй год остается лидером в этом сегменте по квадрату Гартнера. И, что интересно, ее внедряют не только разработческие компании - были рассказы про опыт внедрения TFS в Вымпелкоме и ВТБ24, где разработкой занимаются сторонние подрядчики. А в разработческих ее успешно используют не только для windows-разработки, но и для Linux-разработки (Касперский). Правдо Мас-разработчиков им пересадить на нее не удалось.
А теперь - обзор докладов, на которых я был. Отмечу, что я точно попал не на все интересные доклады - по отзывам и твиттеру, были интересные доклады Асхата Уразбаева, Алексея Баранцева и Сергея Дмитриева, но на конференции параллельно шло четыре трека и я выбрал альтернативные варианты.
==ALM на платформе Microsoft. VS2013 От планирования до эксплуатации. Брайан Келлер, Microsoft==
Обзор основных вкусностей от планирования (работы с задачами), через разработку и управление релизами до мониторинга эксплуатации. Доклад хороший. Только много вкусностей доступны исключительно в Ultimate, а она недешева. Сравнение можно посомтреть на [http://www.visualstudio.com/en-us/products/compare-visual-studio-products-vs сайте MS].
Если говорить о развитии, то MS серьезно вложился в DevOps - мониторинг эксплуатации и быстрое преобразование инцидентов в баги, в VS2012 SP1 появился DevOps System Center. А вот о ветке проектирования практически не говорит, планирование они идет в WorkItem, которые можно объединять в фичи.
И активно развивается VS-online, который в базовой конфигурации бесплатен для 5 разработчиков и довольно дешев для расширения. Да и для других вариантов месячная плата за разработчика не сопоставима с их зарплатами. А на http://aka.ms/ALMVMs - много виртуалок для ALM.
Дальше был рассказ про основные вкусности по циклу Планирование - Разработка - Тестирование - Эксплуатация, вместе с живой демонстрацией. Которые в целом приводят к Continious Value Delivery. Но пересказывать доклад я не буду, отмечу такие вещи как Team Room, быстрое создание нагрузочных тестов для web-приложений, управление релизами и конфигурациями сред, и Application Insight, позволяющий снимать информацию, с помощью которой инцидент на пром.сервере может быть показан в отладчике разработчика (IntelliTrace files).
==Внедрение и эксплуатация Team Foundation Server: опыт полученный внутри Microsoft. Брайан Келлер, Microsoft==
Этот доклад меня разочаровал. Хотелось заглянуть в опыт MS. А в докладе были достижения команды VS. Да, впечатляющие, но именно достижения, а не внутренняя кухня. И пошаговая инструкция как стать участником в dpe (Developer and Platform Evangelism).
==Опыт внедрения крупных комплексных ALM проектов. Круглый стол с представителями Майкрософт, заказчиков и партнеров ==
Это был не круглый стол, а последовательный рассказ о проектах.
* Борис Климов. Внедрял в Касперском, теперь работает в Сбертех - но специально оговорился, что про СберТех вопросы не задавать, там он в отпуске, а будет рассказывать про опыт Касперского.
* Маргарита Николаева. Тоже из Касперского.
* Александр Бирюков бывш.Ситроникс, теперь называется Энвижн.
* Александр Соколов. Вымпелком
* Николай Федоров. ВТБ24
Про проект в '''Касперском''' я уже слышал на предыдущих конференциях, там был зоопарк, а внедряли общее решение. Уложились в два года, в конце 2013 руководство постановило считать внедрение законченным. Тут интересно начало истории. В Касперском - внедрили HP PPM. Обнаружили, что он избыточен, сложен, а местами функционала не хватает. Климов продал идею TFS. И его успешно внедрили, а от PPM отказались.
Однако, есть и подводные камни. Руководству были обещаны прозрачные отчеты отовсюду. В результате была сделана и прикручена собственную систему сбора метрик. И собственная система списания времени взамен PPM. И ряд других своих утилит - не успел записать.
В целом проект шет с приличным административным давлением, это признавали. И жестким ограничением кастомизации через единую точку принятия решений и максимальным сохранением 3 стандартных шаблонов - Agile, Scrum и CMMI. А еще non-win команды в TFS затаскивались сложно. linux помучился и перешел, а Mac-разработка - нет.
БД у них 3Т данных!
'''Ситроникс''' я тоже слышал, там как раз постепенное внедрение. В 2007 у них были Excel плюс VSS и зоопарк хранения версий. И тогда выбрали TFS. Пилотный проект из опытных в компании - чтобы дальше они несли в массы. Но не ключевые - потому что ключевых вынуть сложно. 15 человек, их на полгода отправили в отдельный офис (как раз компания расширялась) - за счет этого вынули из текучки. В проекте обсуждали и настраивали процесс. Проект был сделан, потом членов команды вернули в те команды, откуда брали - чтобы несли опыт. У них - большая кастомизация. Они, кстати, решили проблему персонализированного списания времени на WI (но это из прошлых рассказов). Пример нового WorkItem - Ship, отгрузка новой версии. Три уровня отчетности. Встроенные, Excel, Кубы. Культура работы с кодом. Стандарты кодирования policy.
В презентации есть картинка, как они используют версионирование, посмотреть полезно. У них MAIN, LongDev branch, Features branches, Hotfix.
'''Вымпелком'''. Они - не разработчики. Но тесно связаны с ИТ. Их задача - работать с большим количеством информационных систем, развитие ИТ-ландшафта, в котором зоопарк. Процесс был с 10 летней историей. VSS, HP Quality Center, и еще что-то для тикетов. А команды - еще svn, jira и т.п. Проблемы - полуручной сбор статистики и показателей, ручное управление ресурсами, нет сквозного отслеживание изменений и картинки по задачам исполнителей. То есть верхнеуровневый процесс компании един, но внутри команды работает каждый в своем. И они пошли осознали потребность в единой платформы для себя.
На слайдах есть диаграмма Archimate их разработки ПО.
* Взаимодействие с бизнесом - Lotus Notes, в TFS не погружено. Там ходят документы и идет их согласование, все требования.
* Дальше Project Server. А за ним - SharePoint TFS и TFS.
* Для инфраструктуры - еще Remedy - incident management и CMDB - configuration managerment database - там инфа про железки и инфраструктурное ПО и ответственных за них. Права в TFS на основе CMDB
Для процесса - сильная кастомизация CMMI-шаблона для того, чтобы приблизить к процессу компании. Старались менять аккуратно всякие системные поля, чтобы была комфортная миграция.
С HP Quality - мигрировали и выкинули его. Автосборки. Там где система поставляется с исходным кодом. Они достигают уверенности, что бинарники продакшн собираются с поставленным исходным кодом. Отчетность - во многом тоже своя. Потому что им нужны иерархические показатели с drill-down, в TFS этого нет.
Внедрение продолжается, будет интеграция с incident managerment. Переход на TFS2013 - потому что Web и единое окно.
'''ВТБ24'''. Тоже много поставщиков. Много решений на стеке MS и для него было открытием, что высоконагруженные решения на этом стеке живут. TFS + VS Ultimate как инструмент. Они хотят контролировать что поставляют поставщики, их архитектуру, наращивать компетенции внутри банка. А интеграция TFS с Project Server - великая вещь для него как для руководителя.
Помимо MS в банке есть решения на Java-Oracle. Интегрировали Jdeveloper с TFS, это получилось (хотя как первый блин) и пошли развивать.
Если '''резюмировать''' по всем проектам, то получается, что система отчетностей везде своя, делают дополнительные тулы и/или сильную кастомизацию, но в целом оно живет и работает.
А еще MS разработал свою схему уровни зрелости ALM. Basic. Standardised. Advanced. Dynamic. И развитие по каждом процессов
==Клиентоориентированное нагрузочное тестирование. Александр Рахманов, Астерос Лабс==
Этот доклад оказался для меня приятным бонусом. Очень профессиональный рассказ про решение задачи нагрузочного тестирования при предполагаемом масштабировании системы, которая, при этом, не является изолированной, а взаимодействует со многими другими, и тестирование было проведено с учетом интеграции.
Интеграционное решение для нац.оператором сотовой связи. Приложение "единого окна", интеграционное, взаимодействующее со всем, включая банковские гейты и так далее. Приложение работало в нескольких салонах успешно. Надо было проверить поведение под нагрузкой при тиражировании на всю страну и дать гарантии заказчику.
Автономное тестирование - игнорировало интеграционную составляющую. Тестировать все вместе - непонятно, потому что интеграция велика, тестировать в совокупности - а чья ответственность.
А еще - есть требование "2000 пользователей" - а они, собственно, делают?
По пользователям. Нужна была модель нагрузки. Профиль пользователя: набор бизнес-сценариев + частота использования. У них эти данные были на предпроекте, но вообще можно собрать из логов. И если вы не знаете - он однозначно советует узнать. Из бизнес-сценариев - получаются вызовы подсистем - и можно эмулировать нагрузку. И не забывать ее обновлять при внедрении нового функционала - так как сценарии меняются.
Какие части системы нагружать? У них толстые системы, по одним запросам они идут к внешним системам напрямую, по другим - идут через их сервера, которые идут через внешние машины. Дальше вопрос - как масштабирование с ростом пользователей. Поскольку у каждого пользователя своя машина, это масштабируется.
Внешние системы. Их они не тестируют. Но исходя из профиля своего пользователя они делают профиль нагрузки к внешним системам. получаются профиль нагрузки. В принципе его можно собирать и с боевой системы. Использовали AOP (PostSharp) - аспекты в .Net, чтобы записать вызовы. Профиль - название функции, количество, объем передаваемых данных.
И получается контракт для поставщиков внешней системы, который можно им передать. А для тестирования своей системы - делают эмуляторы (для каких-то они уже были на этапе разработки). При этом заглушки были развернуты все равно на отдельных серверах, чтобы сетевое взаимодействие сохранялось, со всеми задержками. И эмуляторы у них тоже отвечают с задержками.
Среда разработки и тестирования. Развертывают сервера тестирования TestAgent, которые обеспечивают нагрузку на серверную часть. У них было 4 агента по 500 пользователей. Можно в облаке. Агенты управляются TestController'ом, а он уже через VS Ultimate и АРМ управления тестированием.
И инструменты и подходы для разработки тестов.
Наполнение тестов. Там есть поле для ошибок.
* Отдельный тест на каждый сценарий. А не атомарное действие.
* Учитывайте параллельное выполнение тестов. TestAgent запустит их параллельно.
* Учитывайте задержки выполнения действий пользователя. Человек не может нажать 10 кнопок подряд. Иначе будет неоправданное завышение нагрузки.
* Распределяйте пользователей по разным наборам данных. Они создали салон на 2000 консультантов, и получили деградацию производительности.
* Используйте встроенный объект Timer для сбора статистики по отдельным транзакциям. Потому что провал производительности может быть на одном из сценариев, или одной операции, и надо это выявить.
* Автоматизируйте создание тестов. У них огромное число строк кода, 350k строк тестов на 300к строк проекта, но при этом оригинальных строк около 2к, остальное - генерация.
** WCF Storm + WCF Trace - OpenSource проект, который воспроизводит протокол вызовов web-служб. Они еще слипы добавили.
** AOP (PostSharp)
Еще - ограничения, которые надо ставить: процессор не более чем, сетевой канал не более чем, среднее время ответа не более чем, ошибочных транзакций не более чем. И надо заранее договориться, что есть успешный тест. Можно отталкиваться от текущего состояния производительности.
У них основное время заняла разработка эмуляторов внешних систем - чтобы они выдавали нормальный ответ с нормальными задержками.
Для начала надо провести испытания на низкой нагрузки. А потом уже на боевой. Потому что можно напороться на всякие косяки. И нужно делать анализ результатов. По размеру базы, каналам связи и так далее - как увеличивается нагрузка с ростом числа пользователей. С рекомендациями.
В целом MS справился. Хотя некоторые отчеты открывались по 15 минут. Но это по 12 часовой сессии тестирования.
Советы. Обследование - важно. Не бойтесь перетестировать. Полноценное тестирование - дело долгое. У них - месяц два разработчика.При этом они не просто протестировали свою систему, но и решили задачу комплексного тестирования - потому что выдали профили другим системам.
Тестовая среда - у них соответствовала боевой. Удачно развертывали сервера для нового филиала.
==Ключевые практики Microsoft при разработке программного обеспечения. Станислав Брагин, Microsoft==
Зал был переполнен, потому что интерес к практикам MS очень велик. Но, к сожалению, рассказ разочаровал, и не меня одного. Докладчик выписал список практик
* Свободный выбор командами разработчиков средств и инструментов
* Система ролей
* SDL - Secure Development
* PGO - Profiled Guide Optimization.
* Критерии качества.
Но дальше в рассказе был SDL и PGO, при чем по SDL история, так как параллельно в другом зале о нем был доклад с технической составляющей. Это любопытно, но не более.
SDL. Импульс дал XP, где нашли кучу уязвимостей. Там методология раскладки деятельности по всем стадиям процесса. И тулы: SDL modelling для описания уязвимостей, Fuzzing tools, другие. MS его продвигает просто потому, что чем больше разработчиков его будут применять, тем ПО будет менее подвержено разным вирусам и атакам.
PGO - живет 95, но сейчас бурно развился. Не пиарится, в отличие от SDL. И не является обязательным, но завоевывает команды. Это link-time optimization, основанный на прогоне эталонных сценариев. Обычно автотестов. По логу профилирования повторно вызывают оптимайзер компилятора. Встраивание, вызов реальной функции вместо виртуальной "для большинства случаев", оптимизация размещения кода по страницам - частые вместе, а редкие вообще отдельно. Активно применяется в Windows7, именно за счет этого подняли скорость с Vista.
==Особенности организации процесса разработки по промышленным стандартам на платформе 1С. Алексей Лустин, Связной==
Замечательный доклад мем-конструкций. Оно весьма неряшливо, но все равно впечатляюще.
Общая идея - как включить 1С-приложения в общий ALM разработки. Рассматривая 1С-приложения просто как написанные на таком специальном бизнес-ориентированном DSL. Для этого 1С community разработало мостики, которые обеспечивают для 1С подключение репозитария к Git, подключение сборок и Continious Integration через Gradle, Jenkins, Chef, которые, в свою очередь, могут подключаться к TFS. C написанием тестов по BDD, используя, например, Cucumber, и получая результаты в формате xUnit по debug-портам, как позволяет Java. Сами инструменты при этом могут быть бесплатные или платные.
Но главное - это не инструментальные мостики, а понятийные, которые позволяют переводить конструкции, принятые и понятные в среде разработчиков 1С на конструкции, принятые в остальном мире разработчиков. Собственно, это как раз трансляция одних мемов в другие.
А цель - сочетание преимуществ 1С, обеспечивающий специализированный бизнес-ориентированный язык и ядро, быстрая разработка макета приложения и его широкое конфигурирование с промышленным качеством, автоматизированным тестированием и разработкой приложений на других языках с совместной работой. потому что на 1С можно сделать все, но не все делать оправдано.
А еще доклад предварялся весьма любопытным взглядом автора на логику развития средств разработки в целом, но это я повторять не буду. Если выложат запись - посмотрите.
[[Участник:MaksTsepkov|MaksTsepkov]] ([[Обсуждение участника:MaksTsepkov|обсуждение]]) 23:24, 6 февраля 2014 (MSK)
[[Категория:Конференции]]
Возвращаясь к ALM от MS. К сожалению, ее не удалось полноценно дотянуть до уровня бизнеса и описания архитектуры предприятия (enterprise architecture). В VS Ultimate 2012 такая попытка была, но она по факту не взлетела. А это - важная составляющая при сопровождении ИТ-ландшафта больших предприятий, в которых эксплуатируются десятки приложений, постоянно идут процессы модернизации и внедрения новых приложений и перераспределения между ними бизнес-функций. Но, несмотря на эту лакуну, решение MS по ALM покрывает достаточно большую область задач поддержки разработки приложений и их эксплуатации, и это дает представление и идеи о том, какие функции необходимо реализовывать в системе управления ИТ-ландшафтом, и каким образом их правильно интегрировать, независимо от используемых для этого инструментов.
В частных разговорах - хорошая идея на поле управления IT-ландшафтом была у Jazz (IBM), но она, говорят, провалилась. А вот с линейки HP ALM многие слезают, переходя на ALM от MS. Вообще нарекания на продукты HP я слышал не только на этой конференции.
ALM от MS уже второй год остается лидером в этом сегменте по квадрату Гартнера. И, что интересно, ее внедряют не только разработческие компании - были рассказы про опыт внедрения TFS в Вымпелкоме и ВТБ24, где разработкой занимаются сторонние подрядчики. А в разработческих ее успешно используют не только для windows-разработки, но и для Linux-разработки (Касперский). Правдо Мас-разработчиков им пересадить на нее не удалось.
А теперь - обзор докладов, на которых я был. Отмечу, что я точно попал не на все интересные доклады - по отзывам и твиттеру, были интересные доклады Асхата Уразбаева, Алексея Баранцева и Сергея Дмитриева, но на конференции параллельно шло четыре трека и я выбрал альтернативные варианты.
==ALM на платформе Microsoft. VS2013 От планирования до эксплуатации. Брайан Келлер, Microsoft==
Обзор основных вкусностей от планирования (работы с задачами), через разработку и управление релизами до мониторинга эксплуатации. Доклад хороший. Только много вкусностей доступны исключительно в Ultimate, а она недешева. Сравнение можно посомтреть на [http://www.visualstudio.com/en-us/products/compare-visual-studio-products-vs сайте MS].
Если говорить о развитии, то MS серьезно вложился в DevOps - мониторинг эксплуатации и быстрое преобразование инцидентов в баги, в VS2012 SP1 появился DevOps System Center. А вот о ветке проектирования практически не говорит, планирование они идет в WorkItem, которые можно объединять в фичи.
И активно развивается VS-online, который в базовой конфигурации бесплатен для 5 разработчиков и довольно дешев для расширения. Да и для других вариантов месячная плата за разработчика не сопоставима с их зарплатами. А на http://aka.ms/ALMVMs - много виртуалок для ALM.
Дальше был рассказ про основные вкусности по циклу Планирование - Разработка - Тестирование - Эксплуатация, вместе с живой демонстрацией. Которые в целом приводят к Continious Value Delivery. Но пересказывать доклад я не буду, отмечу такие вещи как Team Room, быстрое создание нагрузочных тестов для web-приложений, управление релизами и конфигурациями сред, и Application Insight, позволяющий снимать информацию, с помощью которой инцидент на пром.сервере может быть показан в отладчике разработчика (IntelliTrace files).
==Внедрение и эксплуатация Team Foundation Server: опыт полученный внутри Microsoft. Брайан Келлер, Microsoft==
Этот доклад меня разочаровал. Хотелось заглянуть в опыт MS. А в докладе были достижения команды VS. Да, впечатляющие, но именно достижения, а не внутренняя кухня. И пошаговая инструкция как стать участником в dpe (Developer and Platform Evangelism).
==Опыт внедрения крупных комплексных ALM проектов. Круглый стол с представителями Майкрософт, заказчиков и партнеров ==
Это был не круглый стол, а последовательный рассказ о проектах.
* Борис Климов. Внедрял в Касперском, теперь работает в Сбертех - но специально оговорился, что про СберТех вопросы не задавать, там он в отпуске, а будет рассказывать про опыт Касперского.
* Маргарита Николаева. Тоже из Касперского.
* Александр Бирюков бывш.Ситроникс, теперь называется Энвижн.
* Александр Соколов. Вымпелком
* Николай Федоров. ВТБ24
Про проект в '''Касперском''' я уже слышал на предыдущих конференциях, там был зоопарк, а внедряли общее решение. Уложились в два года, в конце 2013 руководство постановило считать внедрение законченным. Тут интересно начало истории. В Касперском - внедрили HP PPM. Обнаружили, что он избыточен, сложен, а местами функционала не хватает. Климов продал идею TFS. И его успешно внедрили, а от PPM отказались.
Однако, есть и подводные камни. Руководству были обещаны прозрачные отчеты отовсюду. В результате была сделана и прикручена собственную систему сбора метрик. И собственная система списания времени взамен PPM. И ряд других своих утилит - не успел записать.
В целом проект шет с приличным административным давлением, это признавали. И жестким ограничением кастомизации через единую точку принятия решений и максимальным сохранением 3 стандартных шаблонов - Agile, Scrum и CMMI. А еще non-win команды в TFS затаскивались сложно. linux помучился и перешел, а Mac-разработка - нет.
БД у них 3Т данных!
'''Ситроникс''' я тоже слышал, там как раз постепенное внедрение. В 2007 у них были Excel плюс VSS и зоопарк хранения версий. И тогда выбрали TFS. Пилотный проект из опытных в компании - чтобы дальше они несли в массы. Но не ключевые - потому что ключевых вынуть сложно. 15 человек, их на полгода отправили в отдельный офис (как раз компания расширялась) - за счет этого вынули из текучки. В проекте обсуждали и настраивали процесс. Проект был сделан, потом членов команды вернули в те команды, откуда брали - чтобы несли опыт. У них - большая кастомизация. Они, кстати, решили проблему персонализированного списания времени на WI (но это из прошлых рассказов). Пример нового WorkItem - Ship, отгрузка новой версии. Три уровня отчетности. Встроенные, Excel, Кубы. Культура работы с кодом. Стандарты кодирования policy.
В презентации есть картинка, как они используют версионирование, посмотреть полезно. У них MAIN, LongDev branch, Features branches, Hotfix.
'''Вымпелком'''. Они - не разработчики. Но тесно связаны с ИТ. Их задача - работать с большим количеством информационных систем, развитие ИТ-ландшафта, в котором зоопарк. Процесс был с 10 летней историей. VSS, HP Quality Center, и еще что-то для тикетов. А команды - еще svn, jira и т.п. Проблемы - полуручной сбор статистики и показателей, ручное управление ресурсами, нет сквозного отслеживание изменений и картинки по задачам исполнителей. То есть верхнеуровневый процесс компании един, но внутри команды работает каждый в своем. И они пошли осознали потребность в единой платформы для себя.
На слайдах есть диаграмма Archimate их разработки ПО.
* Взаимодействие с бизнесом - Lotus Notes, в TFS не погружено. Там ходят документы и идет их согласование, все требования.
* Дальше Project Server. А за ним - SharePoint TFS и TFS.
* Для инфраструктуры - еще Remedy - incident management и CMDB - configuration managerment database - там инфа про железки и инфраструктурное ПО и ответственных за них. Права в TFS на основе CMDB
Для процесса - сильная кастомизация CMMI-шаблона для того, чтобы приблизить к процессу компании. Старались менять аккуратно всякие системные поля, чтобы была комфортная миграция.
С HP Quality - мигрировали и выкинули его. Автосборки. Там где система поставляется с исходным кодом. Они достигают уверенности, что бинарники продакшн собираются с поставленным исходным кодом. Отчетность - во многом тоже своя. Потому что им нужны иерархические показатели с drill-down, в TFS этого нет.
Внедрение продолжается, будет интеграция с incident managerment. Переход на TFS2013 - потому что Web и единое окно.
'''ВТБ24'''. Тоже много поставщиков. Много решений на стеке MS и для него было открытием, что высоконагруженные решения на этом стеке живут. TFS + VS Ultimate как инструмент. Они хотят контролировать что поставляют поставщики, их архитектуру, наращивать компетенции внутри банка. А интеграция TFS с Project Server - великая вещь для него как для руководителя.
Помимо MS в банке есть решения на Java-Oracle. Интегрировали Jdeveloper с TFS, это получилось (хотя как первый блин) и пошли развивать.
Если '''резюмировать''' по всем проектам, то получается, что система отчетностей везде своя, делают дополнительные тулы и/или сильную кастомизацию, но в целом оно живет и работает.
А еще MS разработал свою схему уровни зрелости ALM. Basic. Standardised. Advanced. Dynamic. И развитие по каждом процессов
==Клиентоориентированное нагрузочное тестирование. Александр Рахманов, Астерос Лабс==
Этот доклад оказался для меня приятным бонусом. Очень профессиональный рассказ про решение задачи нагрузочного тестирования при предполагаемом масштабировании системы, которая, при этом, не является изолированной, а взаимодействует со многими другими, и тестирование было проведено с учетом интеграции.
Интеграционное решение для нац.оператором сотовой связи. Приложение "единого окна", интеграционное, взаимодействующее со всем, включая банковские гейты и так далее. Приложение работало в нескольких салонах успешно. Надо было проверить поведение под нагрузкой при тиражировании на всю страну и дать гарантии заказчику.
Автономное тестирование - игнорировало интеграционную составляющую. Тестировать все вместе - непонятно, потому что интеграция велика, тестировать в совокупности - а чья ответственность.
А еще - есть требование "2000 пользователей" - а они, собственно, делают?
По пользователям. Нужна была модель нагрузки. Профиль пользователя: набор бизнес-сценариев + частота использования. У них эти данные были на предпроекте, но вообще можно собрать из логов. И если вы не знаете - он однозначно советует узнать. Из бизнес-сценариев - получаются вызовы подсистем - и можно эмулировать нагрузку. И не забывать ее обновлять при внедрении нового функционала - так как сценарии меняются.
Какие части системы нагружать? У них толстые системы, по одним запросам они идут к внешним системам напрямую, по другим - идут через их сервера, которые идут через внешние машины. Дальше вопрос - как масштабирование с ростом пользователей. Поскольку у каждого пользователя своя машина, это масштабируется.
Внешние системы. Их они не тестируют. Но исходя из профиля своего пользователя они делают профиль нагрузки к внешним системам. получаются профиль нагрузки. В принципе его можно собирать и с боевой системы. Использовали AOP (PostSharp) - аспекты в .Net, чтобы записать вызовы. Профиль - название функции, количество, объем передаваемых данных.
И получается контракт для поставщиков внешней системы, который можно им передать. А для тестирования своей системы - делают эмуляторы (для каких-то они уже были на этапе разработки). При этом заглушки были развернуты все равно на отдельных серверах, чтобы сетевое взаимодействие сохранялось, со всеми задержками. И эмуляторы у них тоже отвечают с задержками.
Среда разработки и тестирования. Развертывают сервера тестирования TestAgent, которые обеспечивают нагрузку на серверную часть. У них было 4 агента по 500 пользователей. Можно в облаке. Агенты управляются TestController'ом, а он уже через VS Ultimate и АРМ управления тестированием.
И инструменты и подходы для разработки тестов.
Наполнение тестов. Там есть поле для ошибок.
* Отдельный тест на каждый сценарий. А не атомарное действие.
* Учитывайте параллельное выполнение тестов. TestAgent запустит их параллельно.
* Учитывайте задержки выполнения действий пользователя. Человек не может нажать 10 кнопок подряд. Иначе будет неоправданное завышение нагрузки.
* Распределяйте пользователей по разным наборам данных. Они создали салон на 2000 консультантов, и получили деградацию производительности.
* Используйте встроенный объект Timer для сбора статистики по отдельным транзакциям. Потому что провал производительности может быть на одном из сценариев, или одной операции, и надо это выявить.
* Автоматизируйте создание тестов. У них огромное число строк кода, 350k строк тестов на 300к строк проекта, но при этом оригинальных строк около 2к, остальное - генерация.
** WCF Storm + WCF Trace - OpenSource проект, который воспроизводит протокол вызовов web-служб. Они еще слипы добавили.
** AOP (PostSharp)
Еще - ограничения, которые надо ставить: процессор не более чем, сетевой канал не более чем, среднее время ответа не более чем, ошибочных транзакций не более чем. И надо заранее договориться, что есть успешный тест. Можно отталкиваться от текущего состояния производительности.
У них основное время заняла разработка эмуляторов внешних систем - чтобы они выдавали нормальный ответ с нормальными задержками.
Для начала надо провести испытания на низкой нагрузки. А потом уже на боевой. Потому что можно напороться на всякие косяки. И нужно делать анализ результатов. По размеру базы, каналам связи и так далее - как увеличивается нагрузка с ростом числа пользователей. С рекомендациями.
В целом MS справился. Хотя некоторые отчеты открывались по 15 минут. Но это по 12 часовой сессии тестирования.
Советы. Обследование - важно. Не бойтесь перетестировать. Полноценное тестирование - дело долгое. У них - месяц два разработчика.При этом они не просто протестировали свою систему, но и решили задачу комплексного тестирования - потому что выдали профили другим системам.
Тестовая среда - у них соответствовала боевой. Удачно развертывали сервера для нового филиала.
==Ключевые практики Microsoft при разработке программного обеспечения. Станислав Брагин, Microsoft==
Зал был переполнен, потому что интерес к практикам MS очень велик. Но, к сожалению, рассказ разочаровал, и не меня одного. Докладчик выписал список практик
* Свободный выбор командами разработчиков средств и инструментов
* Система ролей
* SDL - Secure Development
* PGO - Profiled Guide Optimization.
* Критерии качества.
Но дальше в рассказе был SDL и PGO, при чем по SDL история, так как параллельно в другом зале о нем был доклад с технической составляющей. Это любопытно, но не более.
SDL. Импульс дал XP, где нашли кучу уязвимостей. Там методология раскладки деятельности по всем стадиям процесса. И тулы: SDL modelling для описания уязвимостей, Fuzzing tools, другие. MS его продвигает просто потому, что чем больше разработчиков его будут применять, тем ПО будет менее подвержено разным вирусам и атакам.
PGO - живет 95, но сейчас бурно развился. Не пиарится, в отличие от SDL. И не является обязательным, но завоевывает команды. Это link-time optimization, основанный на прогоне эталонных сценариев. Обычно автотестов. По логу профилирования повторно вызывают оптимайзер компилятора. Встраивание, вызов реальной функции вместо виртуальной "для большинства случаев", оптимизация размещения кода по страницам - частые вместе, а редкие вообще отдельно. Активно применяется в Windows7, именно за счет этого подняли скорость с Vista.
==Особенности организации процесса разработки по промышленным стандартам на платформе 1С. Алексей Лустин, Связной==
Замечательный доклад мем-конструкций. Оно весьма неряшливо, но все равно впечатляюще.
Общая идея - как включить 1С-приложения в общий ALM разработки. Рассматривая 1С-приложения просто как написанные на таком специальном бизнес-ориентированном DSL. Для этого 1С community разработало мостики, которые обеспечивают для 1С подключение репозитария к Git, подключение сборок и Continious Integration через Gradle, Jenkins, Chef, которые, в свою очередь, могут подключаться к TFS. C написанием тестов по BDD, используя, например, Cucumber, и получая результаты в формате xUnit по debug-портам, как позволяет Java. Сами инструменты при этом могут быть бесплатные или платные.
Но главное - это не инструментальные мостики, а понятийные, которые позволяют переводить конструкции, принятые и понятные в среде разработчиков 1С на конструкции, принятые в остальном мире разработчиков. Собственно, это как раз трансляция одних мемов в другие.
А цель - сочетание преимуществ 1С, обеспечивающий специализированный бизнес-ориентированный язык и ядро, быстрая разработка макета приложения и его широкое конфигурирование с промышленным качеством, автоматизированным тестированием и разработкой приложений на других языках с совместной работой. потому что на 1С можно сделать все, но не все делать оправдано.
А еще доклад предварялся весьма любопытным взглядом автора на логику развития средств разработки в целом, но это я повторять не буду. Если выложат запись - посмотрите.
[[Участник:MaksTsepkov|MaksTsepkov]] ([[Обсуждение участника:MaksTsepkov|обсуждение]]) 23:24, 6 февраля 2014 (MSK)
[[Категория:Конференции]]