Как стать автором
Обновить
30
1.6
Алексей Ионин @aionin

SDLC | ITSM | BPM | QA

Отправить сообщение
отправил в личку
Нужны еще подробности.
В чем заключается ваша технология установки обновления? MSI пакет, файлы меняем, скрипты пускает, базу данных обновляем? Чем сложнее технология, тем потенциально более полезно использовать мощные решения управления развертыванием. CI/CD есть и в GitLab, например.
Коммьюнити пользователей продукта пасется здесь — http://communities.serena.com/community/forums/categories/listings/sda-deployment-automation
На сайте serena нужно заполнить форму и получить доступ дистрибутиву. После установки у вас будет лицензия на 5 узлов, но, увы, также ограниченная 30 днями.
Дистрибутив могу выдать и без формы.
Вот для сглаживания культурных различий и нужны локальные партнеры, как говорится.
Есть интерес, но нет желания заполнять формы — я могу дать ссылку на ftp или dropbox. Хочется посмотреть, но нет времени на установку — приезжаем и показываем. Недостаточно демонстрации — делаем прототип…
Думайте
Видимо, у меня сегодня роль такая «прогонять печали». И вроде погода солнечная в Москве. Может, чувствуется конец лета?!
С ценами все очень просто. Кто-то придумал в США, что цену на сайте показывать не очень правильно — лучше пусть потенциальный клиент поднимет трубку и позвонит ласковым продавцам. Тогда будет возможность поговорить, задать вопросы, и т.д. Для больших и сложных систем или решений это оправдано, на мой взгляд. Опять же лицензирование бывает запутанным. В итоге, Serena не показывает цены у себя и запрещает показывать цены на всех сайтах партнеров.

Это как раз просто. Название компании — Serena. Имя теннисистки — Serena Williams.
На фотографии запечатлен эйс со скоростью 92 мили в час. Serena выпускает важный апдейт.
Но один эйс еще не победа. И новая версия — это только шаг к победе.
:)
Спасибо за идею!
Для экспериментов есть триальная версия на 30 дней. Также есть облачный хостинг, но в США. Там тоже можно сделать временный аккаунт. Период тестирования можно продлевать. Но совсем бесплатной версии SBM нет.
Community версия есть только у другого продукта — SDA — Deployment Automation, но это совсем другая история.

Технологии?
Web контейнер приложений написан на С++ и работает под Microsoft IIS,
Компоненты: сервер нотификаций, SOAP API, JSON API, BPEL сервис, сервер контроля версий приложений — Tomcat.
СУБД: Microsoft SQL или Oracle. Структуры хранения описаны и открыты.
Своя среда разработки: SBM Composer
Т.е. это конечно проприетарная платформа. Решения с этой платформы врядли можно будет куда-то перенести, хоть и можно выгрузить все в XML. Такой бизнес.
С другой стороны система открыта через API, имеет все обязательные компоненты для долгой и безотказной работы тысяч пользователей, есть система управления версиями приложений с функциями развертывания на различных средах.
Помогите мне развеять вашу грусть.
На языке BPEL моделируется только логика взаимодействия решения SBM с внешними web службами других приложений и систем, работающих на той же платформе или совсем других.
BPM — это название подхода управления деятельностью на основе процессов или регламентов. Подробнее на wiki
BPMS — это название класса систем, где моделируется и исполняется приложение, автоматизирующее бизнес-процесс (Business Process Management System). Платформа SBM — относится к этому классу. Сам процесс моделируется в простой нотации workflow. Сразу скажу, что нотация моделирования BPMN не поддерживается. Наша платформа легче, проще, дешевле, чем аналоги с поддержкой BPMN. Моделировать процессы в упрошенной нотации быстрее. Дорабатывать формы UI, структуры хранения данных, отчеты, процедуры и скрипты можно в одной интегрированной среде разработки. Впрочем, нужно самому в этом убедиться…
Первый список статусов вполне узнаваем. Но не задач, а требований или user-story, кому как нравится.
Второй список статусов часто встречается для описания процесса (workflow) управления задачами.
Для управления большим количеством задач и исполнителей важна иерархия задач. Для управления разработкой нескольких продуктов множеством команд аналитиков, разработчиков, тестировщиков одними задачами не обойтись — нужны типы объектов управления со своей иерархией и своим workflow. Для этого и нужны отдельные продукты Jira, RedMine, SBM.
Реализация таких сложных сущностей и отношений в GitLab может получиться слишком громоздкой. Где грань?

Подробнее расскажите, пожалуйста, чего не хватает или как бы вы желали, чтобы работала функциональность просмотра кода (code-review)
Спасибо
Надеюсь, что да.
Согласен. Внес исправления.
Будем совершенствоваться.
Спасибо за комментарий по делу. Действительно, на бесплатном хостинге именно ЕЕ версия.
Исправлю.
GitLab — это web система управления репозиториями GIT, которую можно установить к себе на сервер, а можно работать на хостинге.
На Хабре полно статей именно о GitLab, так что я не думаю, что кто-то запутался.
Статья написана в блог компании — не нравится, не читайте.
"Диссертабельно".
Много математики. Действительно, сегодня мало кто так глубоко задумывается над эффективностью зачастую готовых элементов интерфейса.
Спасибо за хорошие вопросы.
1. Это, конечно, так. Термин «Потребности» нужно понимать действительно в широком смысле. Однако на практике, функциональные требования настолько доминируют над сознанием и отношениями, что прочие «смыслы» зачастую остаются на бумаге. Более того, не функциональные требования часто проверяются только в первой версии, а для последующих уже нет. Вот, например, классическая заглушка для ФТР одного из наших проектов
8. Обеспечение доступности
Функционально-технические решения по обеспечению доступности не изменяются и соответствуют описанию в соответствующем разделе ФТР предыдущей версии N.N


2. Нет, не противопоставление. Скорее я хотел донести идею, что использование автоматических средств анализа исходного кода — это своеобразный недорогой «code review». Разумеется, просмотр кода опытными разработчиками или архитекторами может помочь выявить серьезные ошибки проектирования, например. Однако, использовать такой ресурс для более простых задач анализа текста программы, которые гораздо эффективнее и быстрее решает соответствующий инструмент — это расточительство времени и сил. Опять же я привёл примеры, когда альтернативы анализаторам кода просто нет.
Что касается использование анализатора кода в качестве средства обучения хорошим правилам программирования, то здесь я бы поспорил. Когда анализатор выдаст исчерпывающую справку о найденной уязвимости с подробным описанием возможных последствий, предоставит примеры того, как код исправить, укажет на строки кода, где эта уязвимость обнаружена — то это уже вполне можно считать элементом обучения.

Например, для C# из Kiuwan

Overload Equals method on value types
Description
For the value type «structure', default implementation of the method that determines the equality of two objects (Equals) habitually it will have a performance lower than a personalized implementation and because of this it recommends to personalize this method and Violation will appear when it is not like that.
Code
OPT.CSHARP.Csharp.OverloadingEqualsValueTypes
Reference
msdn.microsoft.com/en-us/library/7h9bszxx(VS.80).aspx
Violation code

public struct A {     //VIOLATION
      int x;
     }


Fixed code

public struct A {
         int x;

         public override bool Equals(object o)  //OK
         {
             A obj = (A)o;
             return (this.x == obj.x);
         }
    }


3. Базовым результатом работы любого анализатора кода будет список найденных уязвимостей, ошибок, замечаний. Всё самое интересно начинается потом. Как работать с этим списком? Классификация, сортировка, группировка, приоритизация. Над этим слоем можно построить более общие отчеты по обнаруженным проблемам.

Выше — общая статистика по приложению

Выше — статистика по портфелю приложений, командам разработки или внешним исполнителям и многое другое.
Пример общего отчета анализа С# приложения.
И это только срез отчетов после одной проверки. А если процедуру производить регулярно, то появится возможность посмотреть на информацию в динамике — кто улучшает качественные характеристики, кто ухудшает, по каким показателям и т.д.
Еще на один момент я обращал внимание в статье — насколько важно обнаруженные уязвимости преобразовать в задачи. Здесь два аспекта — оценка сложность исправления и доставка задачи исполнителю. И то и другое, например, есть в Kiuwan — система помогает примерно оценить в часах, днях сколько нужно времен на исправление. Есть выгрузка в Excel. Есть интеграция с Jira / SBM. Наверное можно и с другими трекерами установить „рабочие отношения“.
Вот теперь это уже не только инструмент самообразования программиста, а полноценный инструмент контроля качества серьезной организации, как мне представляется.

4. Как известно, есть две парадигмы в отношении управления людьми. Или нужно исходить из того, что все сотрудники лентяи, бездари, халтурщики и т.д. или наоборот, что они все молодцы, болеют за дело, как за свое, пожертвуют своим временем и здоровьем ради проекта и т.д. Я обычно исхожу из „второй“, а получается как в „первой“. :)

5. Я даже скажу больше. Важно не только отбрасывать ложные срабатывания, но и „отключать“ целые типы уязвимостей, которые для ваших обстоятельств использования приложения, например, значения не имеют.
В Kiuwan пользователь может отключить отдельные найденные ошибки — »Mute" — и они больше не попадут в отчет даже при повторном анализе. Либо настроить свою модель качества приложений, повысив приоритет одних характеристик и снизив для других, что отражается и для расчета метрик и для поиска уязвимостей. Либо загрузить свои правила обнаружения дефектов.

Как-то так. Надеюсь, что ответил на ваши вопросы.
С этой точки зрения, любые платформы-конструкторы бизнес-приложений, игр, web-сайтов и платные, и бесплатные «привязывают» к себе пользователя. Совершенно невозможно себе представить мягкий быстрый переход, например, с WordPress на Goomla или с Jira на SBM. Но так ли это плохо?! Платформы-конструкторы действительно сильно упрощают многие задачи и операции разработки новых приложений, резко повышают эффективность разработки. Если смотреть на этот вопрос еще шире, то даже чистое программирование на C# на самом деле резко сужает для вас список сред разработки, не так ли?
Ближе к теме статьи, как уже было замечено Throwable, на BPEL никто не автоматизирует процессы. Даже у нас на платформе SBM для этого используется своя простая нотация workflow (не BPMN, к сожалению), а модули, написанные на BPEL, только дополняют основной процесс необходимой функциональностью. Например, до или после действий пользователя на форме приложения, обратиться к внешней системе за информацией в синхронном режиме или записать во внешнюю систему информацию в асинхронном.
Еще один плюс — модуль на BPEL запросто можно переносить из среды разработки в промышленную среду вместе с кодом самого приложения без необходимости менять вручную массу параметров соеднения в коде.
По-моему, это здорово и очень технологично. И права, и банковская карта, и паспорт, и загранпаспорт (для Европы), и социальная карта, и ИНН — одной карточкой. Никто же не мешает иметь несколько банковских карт, кому не нравится выбор государства. Социальная карта москвича, к слову, привязана к Банку Москвы.

А у нас все отдельными документами — целую сумку надо таскать. Новое водительское удостоверение (права), например, вышло из формата кредитной карты, и строго говоря, не является международными. Т.е. еще один документ надо делать и возить с собой.

Но даже не это важно. Обидно, что МЫ такое же решение не получим, увы, еще очень и очень долго…
По мнению Forrester — Subversion — лучшая система версионного контроля в категории систем без функционала управления изменениями. В подкупе Gartner сложно заподозрить, тем более что Subversion — бесплатная система. The Forrester Wave™: Software Change And Configuration Management, Q2 2007

По-моему мнению, неправильно сводить выбор технологического инструментария для конфигурационного управления к удобству управления ветками. Есть требования инфраструктурные, есть процессные, есть секьюрные требования и т.д. Например, для CMM 3 необходима интеграция системы конфигурационного управления с системой управления изменениями (issue management, change management). Где-то требуется обязательный доступ через WEB, где-то высокие требования к ограничениям прав доступа к исходникам. А кто-то жить не может без интеграции со средой разработки. Не последнюю роль играют организационные факторы — наличие на рынке труда специалистов, знающих инструмент, а также наличие технической поддержки продукта в России.

Информация

В рейтинге
1 106-й
Откуда
Россия
Дата рождения
Зарегистрирован
Активность