Чуть было не пропустил конференцию 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-разработки (Касперский). Правдо Мас-разработчиков им пересадить на нее не удалось.
А теперь - обзор докладов, на которых я был. Отмечу, что я точно попал не на все интересные доклады - по отзывам и твиттеру, были интересные доклады Асхата Уразбаева, Алексея Баранцева и Сергея Дмитриева, но на конференции параллельно шло четыре трека и я выбрал альтернативные варианты.
Обзор основных вкусностей от планирования (работы с задачами), через разработку и управление релизами до мониторинга эксплуатации. Доклад хороший. Только много вкусностей доступны исключительно в 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).
Этот доклад меня разочаровал. Хотелось заглянуть в опыт MS. А в докладе были достижения команды VS. Да, впечатляющие, но именно достижения, а не внутренняя кухня. И пошаговая инструкция как стать участником в dpe (Developer and Platform Evangelism).
Это был не круглый стол, а последовательный рассказ о проектах.
Про проект в Касперском я уже слышал на предыдущих конференциях, там был зоопарк, а внедряли общее решение. Уложились в два года, в конце 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 их разработки ПО.
Для процесса - сильная кастомизация 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 и АРМ управления тестированием.
И инструменты и подходы для разработки тестов.
Наполнение тестов. Там есть поле для ошибок.
Еще - ограничения, которые надо ставить: процессор не более чем, сетевой канал не более чем, среднее время ответа не более чем, ошибочных транзакций не более чем. И надо заранее договориться, что есть успешный тест. Можно отталкиваться от текущего состояния производительности.
У них основное время заняла разработка эмуляторов внешних систем - чтобы они выдавали нормальный ответ с нормальными задержками.
Для начала надо провести испытания на низкой нагрузки. А потом уже на боевой. Потому что можно напороться на всякие косяки. И нужно делать анализ результатов. По размеру базы, каналам связи и так далее - как увеличивается нагрузка с ростом числа пользователей. С рекомендациями.
В целом MS справился. Хотя некоторые отчеты открывались по 15 минут. Но это по 12 часовой сессии тестирования.
Советы. Обследование - важно. Не бойтесь перетестировать. Полноценное тестирование - дело долгое. У них - месяц два разработчика.При этом они не просто протестировали свою систему, но и решили задачу комплексного тестирования - потому что выдали профили другим системам.
Тестовая среда - у них соответствовала боевой. Удачно развертывали сервера для нового филиала.
Зал был переполнен, потому что интерес к практикам MS очень велик. Но, к сожалению, рассказ разочаровал, и не меня одного. Докладчик выписал список практик
Но дальше в рассказе был SDL и PGO, при чем по SDL история, так как параллельно в другом зале о нем был доклад с технической составляющей. Это любопытно, но не более.
SDL. Импульс дал XP, где нашли кучу уязвимостей. Там методология раскладки деятельности по всем стадиям процесса. И тулы: SDL modelling для описания уязвимостей, Fuzzing tools, другие. MS его продвигает просто потому, что чем больше разработчиков его будут применять, тем ПО будет менее подвержено разным вирусам и атакам.
PGO - живет 95, но сейчас бурно развился. Не пиарится, в отличие от SDL. И не является обязательным, но завоевывает команды. Это link-time optimization, основанный на прогоне эталонных сценариев. Обычно автотестов. По логу профилирования повторно вызывают оптимайзер компилятора. Встраивание, вызов реальной функции вместо виртуальной "для большинства случаев", оптимизация размещения кода по страницам - частые вместе, а редкие вообще отдельно. Активно применяется в Windows7, именно за счет этого подняли скорость с Vista.
Замечательный доклад мем-конструкций. Оно весьма неряшливо, но все равно впечатляюще.
Общая идея - как включить 1С-приложения в общий ALM разработки. Рассматривая 1С-приложения просто как написанные на таком специальном бизнес-ориентированном DSL. Для этого 1С community разработало мостики, которые обеспечивают для 1С подключение репозитария к Git, подключение сборок и Continious Integration через Gradle, Jenkins, Chef, которые, в свою очередь, могут подключаться к TFS. C написанием тестов по BDD, используя, например, Cucumber, и получая результаты в формате xUnit по debug-портам, как позволяет Java. Сами инструменты при этом могут быть бесплатные или платные.
Но главное - это не инструментальные мостики, а понятийные, которые позволяют переводить конструкции, принятые и понятные в среде разработчиков 1С на конструкции, принятые в остальном мире разработчиков. Собственно, это как раз трансляция одних мемов в другие.
А цель - сочетание преимуществ 1С, обеспечивающий специализированный бизнес-ориентированный язык и ядро, быстрая разработка макета приложения и его широкое конфигурирование с промышленным качеством, автоматизированным тестированием и разработкой приложений на других языках с совместной работой. потому что на 1С можно сделать все, но не все делать оправдано.
А еще доклад предварялся весьма любопытным взглядом автора на логику развития средств разработки в целом, но это я повторять не буду. Если выложат запись - посмотрите.
Любые правки этой статьи будут перезаписаны при следующем сеансе репликации. Если у вас есть серьезное замечание по тексту статьи, запишите его в раздел «discussion».
Репликация: База Знаний «Заказных Информ Систем» → «Блог:Максима Цепкова/2014-02-06: ALM Summit-2014»