2014-02-06: ALM Summit-2014

Текущая версия на 11:38, 18 мая 2014

Чуть было не пропустил конференцию MS 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, а она недешева. Сравнение можно посомтреть на сайте 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С можно сделать все, но не все делать оправдано.

А еще доклад предварялся весьма любопытным взглядом автора на логику развития средств разработки в целом, но это я повторять не буду. Если выложат запись - посмотрите.