Заметки консультанта

Шамрай Александр Владимирович

Archive for Июль 2009

Тестируем уязвимости Web-сайтов

Posted by Шамрай Александр на Июль 30, 2009

Всемирная паутина уже давно перешагнула за границы обычного источника информации и места для обмена сообщениями и стала привычным местом обитания. Все больше и больше организаций использует интернет как средство для продажи своей продукции, услуг или как место, через которое они могут заявить о себе. Другие  же компании специализируются на разработке Web-сайтов для того, чтоб удовлетворить желание первых. Но как и монета, интернет имеет две стороны. А вторая сторона — это реальная возможность  того, что Web-сайт может быть взломан и могут быть украдены конфиденциальная информация или средства клиентов организации. Часто мы слышим по новостям сломали то, сломали это, украли чертежи F-35 и т.д. А еще большего мы реально не узнаем, т.к. хвастаться, что его взломали, навряд ли кому-либо нравиться.  Тулов, которые бы помогли проверить сайт на уязвимости, мало на рынке ПО, я по крайней мере знаю одну — IBM Rational AppScan.

Я уже пытался рассмотреть эту проблематику ранее в статье: Контроль безопасности Web-ресурсов с помощью IBM Rational AppScan

Ниже презентация IBM, которая показывает, как можно интегрировать процесс тестирования безопасности сайтов в общий процесс тестирования компании:

Реклама

Posted in AppScan, IBM Rational | Отмечено: , , , , , , | Leave a Comment »

Семинар 10 сентября в Санкт-Петербурге по сравнению возможностей IBM Rational и MS Team System

Posted by Шамрай Александр на Июль 29, 2009

Давно хотели провести мероприятие, семинар, тренинг или что-то подобное, для того, чтобы в одном месте продемонстрировать решения IBM Rational и Microsoft.

Не секрет, что среди коммерчески активных игроков IBM Rational и Microsoft очень сильно конкурируют. В своей деятельности мы предлагаем и внедряем решения от обоих производителей, в зависимости от многих факторов (размер компании, бюджет,  платформа разработки и так далее) влияющих на рекомендации в выборе.

Идея данного семинара проста: взять и показать инструменты обоих производителей работают в схожих задачах. То есть мы попробуем взять некие реальные практические задачи и “пропустим” их через средства IBM Rational и Microsoft.

Ну, и, собственно, постараемся ответить на все вопросы аудитории.

Посмотреть программу и записаться можно по ссылке ниже

Уникальный семинар 10 сентября в Санкт-Петербурге:”Эффективное использование технологи IBM Rational и Microsoft для улучшения процессов разработки ПО: идеология, практика и методология. Выбор оптимальной платформы.”

Posted in Новости, Семинары, IBM Rational, Microsoft | Отмечено: , , , , , , , , , , , | 1 Comment »

Графическое руководство по командам ClearCase

Posted by Шамрай Александр на Июль 26, 2009

В интернете хватает уже исчерпывающих руководств по ClearCase. Но одна из сложностей команд ClearCase – это большое количество параметров, в последовательности которых путаются даже опытные менеджеры ClearCase. Сегодня нашел интересный ресурс, который в отличии от стандартных мануалов, описывает не только набор параметров для команд, но и рисует графическое представление их последовательности. Адрес сайта: http://www.samecs.com/commands.htm

 

Posted in ClearCase, IBM Rational | Отмечено: , , | Leave a Comment »

Как сделать пакет видимым из ClearQuest Designer

Posted by Шамрай Александр на Июль 24, 2009

<< Перейти в раздел “ClearQuest FAQ”

Если пакет установлен как скрытый и  не виден в списке пакетов из ClearQuest Designer, то необходимо сделать следующее:

  1. Запустить редактор реестра
  2. Перейти в ветку «HKEY_LOCAL_MACHINE\Software\ Rational Software\ClearQuest Packages«
  3. Найти необходимый пакет и перейти в подкаталог реестра этого пакета «Keywords«
  4. Удалить параметр «Hide_me«

Posted in ClearQuest FAQ, IBM Rational | Отмечено: , , , | 2 комментария »

Как включить автоматический анализ кода при возврате изменений TFS

Posted by Шамрай Александр на Июль 22, 2009

<< Перейти в раздел «Team Foundation Version Control FAQ»

Автоматический анализ кода помогает организовать поставку изменений в версионное хранилище только соответствующих определенным стандартам безопасности, наименования и т.д. Для того чтоб включить эту проверку для проекта TFS необходимо выполнить следующие шаги:

  • Правой клавишей мыши на проекте в командном обозревателе выбрать «Параметры командного проекта — Система управления версиями…»

  • В окне параметров выбрать вкладку «Политики возврата» и нажать кнопку «Добавить…». В Появившемся окне нужно выбрать «Анализ кода».

  • Выбрать необходимые правила проверки. Если какие-то пункты являются критическими, то для них можно указать «Рассматривать предупреждение как ошибку»

  • В дальнейшем, при попытке вернуть на сервер TFS неудовлетворяющие выбранным стандартам изменения, будет отображена следующая ошибка:

Posted in Microsoft, Team Foundation Server FAQ, Version Control FAQ, Visual Studio | Отмечено: , , , , , | Leave a Comment »

Как ассоциировать изменения с рабочими элементами TFS

Posted by Шамрай Александр на Июль 21, 2009

<< Перейти в раздел «Team Foundation Work Item Tracking FAQ»

Для того чтоб связать внесенные изменения в версионную систему с рабочими элементами, необходимо выполнять следующие действия:

  • При возврате (check in) изменений на сервер TFS на форме регистрации необходимо выбрать вкладку «Рабочие элементы»
  • Выбрать запрос, с помощью которого можно получить доступ к необходимому рабочему элементу
  • Выбрать необходимый рабочий элемент и действие:
    • Партнер – изменения ассоциируются с рабочим элементом
    • «Наименование действия» — при ассоциации изменений рабочий элемент переводится в следующее состояние

  • После удачной регистрации изменений, информация о них должны появиться на вкладке «Ссылки» рабочего элемента

<< Перейти в раздел «Team Foundation Version Control FAQ»

Posted in Microsoft, Team Foundation Server FAQ, Version Control FAQ, Visual Studio, Work Item Tracking FAQ | Отмечено: , , , , , | Leave a Comment »

Как можно поменять стандартные шаблоны процессов TFS

Posted by Шамрай Александр на Июль 20, 2009

<< Перейти в раздел “Team Foundation Work Item Tracking FAQ”

Стандартные шаблоны процессов, которые поставляются вместе с TFS, можно редактировать с помощью встроенных средств TFS (witexport, witimport) и с помощью утилит Power Tools. Более подробно можно узнать из статей:

Posted in Microsoft, Team Foundation Server FAQ, Visual Studio, Work Item Tracking FAQ | Отмечено: , , , , , | Leave a Comment »

Как удалить проект TFS?

Posted by Шамрай Александр на Июль 17, 2009

<< Перейти в раздел “Team Foundation Server Admin FAQ”

Для того чтоб удалить проект на сервер TFS, необходимо воспользоваться утилитой «TFSDeleteroject.exe», которая находится в каталоге «<диск: >\Program Files\Microsoft Visual Studio 9\Common7\IDE». Команда использует по следующему шаблону:

TFSDeleteproject [/q] [/force] [/server:Имя_сервера] Имя_проекта

, где:

  • /q – не запрашивать подтверждения пользователя
  • /force – выполнять удаление даже если некоторые составляющие не были удалены
  • /server:Имя_сервера – имя сервера, на который содержит командные проекты
  • Имя_проекта – наименование проекта, который необходимо удалить

 Пример:

TFSDeleteProject /server:TFSProjectServer ShpFaceProject

Posted in Admin FAQ, Microsoft, Team Foundation Server FAQ, Visual Studio | Отмечено: , , , , , | Leave a Comment »

Как создать свою задачу для TeamBuild с помощью Team Foundation Build API

Posted by Шамрай Александр на Июль 15, 2009

<< Перейти в раздел «Team Foundation Build FAQ»

Для того чтоб сделать свою отдельную задачу, которая будет выполняться при сборке проекта, необходимо:

  • Создать новый проект как «Class Library».
  • Для этого проекта нужно подключить следующие связи:

Microsoft.Build.Framework
Microsoft.Build.Utilities

  • Отредактировать новый класс по следующему сценарию:

……………
using
Microsoft.Build.Framework;
using Microsoft.Build.Utilities;
namespace SampleBuildTask
{
    public class CustomTask : Task
    {
        private string Argument;
        [Required]
        public string Argument
        {
            get { return Argument; }
            set { Argument = value; }
        }
        public override bool Execute()
        {
            
Log.LogMessage(«My custom task for project: {0}», Argument)
            return true;
        }
    }
}

  • Собрать проект.
  • Перейти к фалу проекта командной сборки (на сервере TFS с расширением «.proj») и изъять его на редактирование.
  • Перед секцией </Project> внести изменения по следующему шаблону:

    <UsingTask TaskName=»SampleBuildTask.CustomTask»
            AssemblyFile=»Путь_к_проекту\bin\Debug\SampleBuildTask.dll» />
            <Target Name=»BeforeDropBuild»>/
                <CustomTask Argument=»$(SolutionRoot)» />
            </Target>

  • Сделать «check in» для проекта сборки и можно сборку выполнять.
  • В результате работы сборки в ее журнале должны быть строки: «My custom task for project: Путь к проекту».

Posted in Build FAQ, Microsoft, Team Foundation Server FAQ, Visual Studio | Отмечено: , , , , , | Leave a Comment »

Версионный контроль Visual Studio Team System 2010

Posted by Шамрай Александр на Июль 14, 2009

Систем версионного контроля на сегодняшний день уже много, как коммерческих, так и бесплатных (Microsoft VS TFS, IBM Rational ClearCase, SVN и т.д.). И по большому счету, все они решают одни и те же задачи, но каждый немного по-своему. Можно выделить следующие задачи:

  1. Обеспечение механизмов безопасного хранения проектных артефактов. Все что ни создается в течение проекта (файл, документ, модель, тестовый сценарий и т.д.) – все это имеет важное значение для проектной команды и потеря любого из этих компонентов крайне нежелательна и может привести к задержкам работ. Поэтому для всего, что команда создает, с чем работает каждый день, должно быть специальное хранилище, которое обеспечит не только хранение файла, но и хранение всей истории развития каждого элемента этого хранилища.
  2. Обеспечение механизмов доступа к проектным артефактам. Собственно возможность чтения и изменения всех проектных артефактов. Причем, система должна обеспечить доступ не только к последней версии файла, но и предоставлять возможность просмотра любой ранее созданной версии элемента хранилища, для того, чтоб можно было понять почему было внесено то или иное изменение. И тут же не стоит забывать о разграничении доступа к различным элементам версионного хранилища, т.е. к одному и тому же файлы различные пользователи могут иметь доступ на чтение/запись или только на чтение.
  3. Обеспечение параллельного доступа к проектным артефактам. Параллельная разработка – это уже давно стандарт для любой команды разработки ПО. Одновременное изменение одного и того же файла несколькими членами команды и объединение этих изменений с возможностью разрешения конфликтных блоков исходного кода. Использование веток для распределения разработки между внутренними группами или по функционалу, разрешение конфликтных ситуаций при слиянии веток.

Это основные задачи, которые должны выполнять системы версионного контроля. Кроме этого, при выборе такой системы для своей организации, следует учитывать еще и следующие факторы:

  • Интеграция с существующими системами управления изменениями и другими смежными системами. Интеграция с системой управления изменениями, управления требованиями и т.д. обеспечивает возможность понять для чего были написаны какие строки исходного кода, сколько и что было добавлено и изменено при реализации конкретных требования или задачи. Готовые интеграции присущи в основном коммерческим системам, ограничение только в том, что интегрированы они только с системами того же производителя. Для бесплатных систем интеграции обычно не поставляются.
  • Расширяемость системы. Возможность собственной разработки интеграции с системами, если необходимая отсутствует. Открытое API позволяет написать свои методы взаимодействия со смежными системами или реализовать какие-то дополнительные функции, которые будут полезны в разработке.
  • Командная строка. Не самая главная, но полезная функция. Использование командной строки позволяет автоматизировать некоторые рутинные процессы, например, связанные со сборкой определенной версии системы.

Checkin/chekout

Основные функции любой версионной системы (Check in/chek out), описывать которые большой необходимости нет. С этими функциями знаком каждый разработчик, который уже имел опыт общения с «версионниками»:

  • Chek out – это изъять на редактирование файл. При этом TFS дает возможность следующих операций при редактировании, которые позволяют избежать конфликтных ситуаций при работе над одним файлом нескольких разработчиков:
    • Эксклюзивное извлечение, т.е. файл может редактировать только тот пользователь, который первый его взял на редактирование;
    • Извлечение только для редактирования, т.е. когда файл могут редактировать несколько разработчиков, но изменения они могут регистрировать только в том случае, если предыдущий до него разработчик зарегистрировал свои. При этом используется проверка на возможные конфликты между внесенными изменениями.
  • Check in – вернуть/зарегистрировать сделанные с файлом или группой файлов изменения.

Рисунок 1. Взятие на редактирование

Аннотирование

Аннотация кода полезная в повседневной практике функция, которая позволяет просмотреть все изменения, проведенные над файлом, на протяжении всей его длительной истории развития. Это позволяет быстро разобраться новым разработчикам или бывалым восстановить в памяти, что было сделано с файлом, и понять, зачем были сделаны те или иные изменения. Например, если проводились какие-то локальные эксперименты, то результаты этих работ можно зафиксировать в комментариях к изменениям. И когда новый разработчик по истечении времени решит заняться подобными, то ему можно выполнить аннотирование кода, увидеть результаты и не заниматься пустой тратой времени.

Рисунок 2. Аннотирование кода

Отложить

Еще одна полезная функция, которая означает «отложить текущие изменения». Эта функция полезна в следующих случаях:

  • Если пришли новые более важные задачи, а уже выполнено много изменений для текущей работы. И получается, что и откатить некуда и зарегистрировать изменения еще рано. Для того, чтоб не копировать в какие-то временные папочки на локальном диске текущие файлы, которые иногда имеют свойства пропадать, в TFS есть функция «отложить», которая позволяет сохранить все сделанные изменения на сервере без их регистрации в основном потоке разработки. После того как срочные работы будут выполнены, всегда можно вернуться к отложенным изменениям и доделать свою работу.
  • Если есть необходимость передать код на рецензирование. Разработчик может выполнить операцию «отложить» для своих изменений и дать необходимую информацию рецензенту. Рецензент может найти эти отложенные изменения и «подгрузить» их к себе в рабочее пространство. После того, как проверка кода закончена, свое рабочее пространство рецензент может вернуть в исходное состояние, т.е. до того как он начал рецензирование.

Рисунок 3. Отложить

Ветвление

Говорить, почему использование веток полезно, наверно, лишнее. Используют различные подходы в использование веток:

  • По функционалу. Для продукта создается основной поток разработки, в котором будет храниться готовый продукт. Для каждой функциональной возможности создается отдельная ветка. Когда функционал реализован и оттестирован, все изменения переносятся в основной поток.
  • По группам разработки. Для каждой группы разработки создается отдельный поток и используется отдельный поток, в котором будет использоваться как основной и с ним будут синхронизироваться все группы. Такой подход полезен, когда в организации большое количество разработчиков или используется географически разделенная разработка.
  • По заказчикам. Если в организации есть продукт, который поставляется нескольким заказчикам, и для каждого заказчика формируются отдельные уникальные функциональные возможности, то можно использовать для отдельного заказчика отдельную ветвь.
  • И многое другое. С различными видами ветвления можно познакомиться тут: Microsoft Team Foundation Server Branching Guidance.

Ветвление приобрело новые возможности в TFS 2010. Эти возможности связаны с визуализацией иерархии потоков разработки (см. Рисунок 4).

Рисунок 4. Иерархия веток

Кроме общей визуализации теперь доступна визуализация направления изменений между потоками разработки. Такой визуализатор позволяет сделать следующее:

  • Проанализировать общий ход изменений и направление слияний между потоками. С помощью инструмента можно увидеть, как проходило слияние между ветками и какие потоки еще нуждаются в объединении.
  • Просмотреть свойства каждого набора изменений. Можно увидеть всю необходимую информацию об изменениях, включая дату, пользователя, комментарий и т.д.
  • Выполнить сравнение между потоками. Можно увидеть различия между потоками разработки, как в наборе папок и файлов, так и между исходными текстами конкретных фалов.
  • Выполнить слияние веток. Простым перетаскиванием изменений между изображениями веток можно выполнить слияние потоков разработки.

Рисунок 5. Просмотр истории изменений

Рисунок 6. Направление изменений

Разрешение конфликтов

Когда возникают конфликтные ситуации?

  1. Изменение одного файла. При изменении двумя разработчиками одного и того же файла необходимо слияние их результатов работы.
  2. Возврат отложенных изменений. После того как разработчик делал операцию «отложить» для того, чтоб выполнить какие-то другие задачи, он через какое-то время возвращает выполненные им ранее изменения. Сделав возврат, он фактически возвращается к предыдущему состоянию своей разработки и продолжает незаконченную работу. И понятно, что то что он сделает для продолжения отложенной работы не должно конфликтовать с тем, что было сделано ранее.
  3. Слияние потоков разработки. Когда необходимо объединить изменения двух веток разработки, то конечно также будут возникать конфликты.

Большинство всех конфликтных ситуаций TFS попытается решить автоматически, но это невозможно во всех случаях. Поэтому в состав TFS включена утилита, которая позволяет решить конфликты в ручном режиме.

Рисунок 7.Список конфликтов

Рисунок 8. Ручное слияние

Дополнительно

Posted in Microsoft, Team Foundation Server, Visual Studio | Отмечено: , , , , | Leave a Comment »

 
%d такие блоггеры, как: