Лучший подход к проведению аудита физической конфигурации CMMI?

Question

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

Часть обязанностей заключается в проведении на регулярной основе (они все еще определяют регулярную основу, это будет ежеквартально или ежемесячно) аудит физической конфигурации.По сути, это проверка версий исходного кода, развернутых в производстве, по сравнению с тем, что мы считаем версиями исходного кода в производстве.

Наш проект представляет собой относительно небольшое веб-приложение, написанное на Java.Мы работаем с типами файлов java, jsp, xml, файлами свойств и пакетами sql.

Проблема, с которой я столкнулся (и выразила, но, похоже, игнорирую), заключается в том, как мне физически войти на рабочий сервер и проверить версии файлов, и даже если бы я мог, это заняло бы смехотворное количество времени?

Версии файла даже не находятся в файле (т.в комментарии или что-то в этом роде).Было предложено разместить видимые номера версий на каждом экране, который также будет виден пользователям.Мне это тоже показалось смешным, поскольку сами экраны представляют собой лишь небольшую часть кода, который мы поддерживаем.

В настоящее время мы используем инструменты Netbeans для нашей IDE и Serena Dimensions в качестве инструмента управления версиями.

Я специально ищу идеи о том, как провести этот аудит более автоматизированным способом, который будет одновременно точным и не отнимает много времени.

В настоящее время моя идея состоит в том, чтобы добавить комментарий в начало каждого файла, содержащий номер версии этого файла, сценарий, который запускается при создании производственной сборки для создания XML-файла или чего-то подобного, содержащего имя файла и файл версии каждого файла. файл в сборке.Затем, когда мне нужно провести аудит, я иду на производственный сервер, беру XML-файл с информацией, программно сравниваю его с тем, что, по нашему мнению, находится в производстве, и выдаю отчет.

Есть идеи получше.Я знаю, что это уже должно было быть сделано, и мне кажется сумасшедшим, что я не нашел никаких других ресурсов.

Answer 1

Вы можете вычислить хеш SHA1 исходных файлов на производственном сервере и сравнить это значение хеша с версиями, хранящимися в системе контроля версий. Если вы можете найти тот же хеш в управлении исходным кодом, то вы знаете, какая версия находится в производстве. Если вы не можете найти тот же хеш в управлении исходным кодом, то в производстве есть неотслеживаемые модификации, и ваше новое название должности оправдано. :)

Answer 2

Типичная ловушка, в которую попадают организации, когда CMMI пытается во всем переусердствовать.Если бы я мог что-то предложить, я бы начал с малого и делал только то, что вам нужно.Поэтому заранее рассмотрите любые проблемы, которые могли у вас возникнуть в области CM.

CMMI описывает, ЧТО организация должна делать, но оставляет на ваше усмотрение КАК.А Спецификация CMMI, главу 2 стоит прочитать — она описывает обязательные, ожидаемые и информативные компоненты спецификации — в основном требуются цели, ожидаемые практики и все остальное информативно.Это означает, что существует лишь небольшая часть спецификации, которую оценщик CMMI может напрямую потребовать – цели.На уровне практики допустимо использовать либо описанные практики, либо или приемлемые альтернативы им.

В случае аудита конфигурации целью SG3 является «Установление и поддержание целостности базовых показателей».SP3.2 говорит: «Выполните аудиты конфигурации для поддержания целостности базовых линий конфигурации». Здесь ничего не указывается о том, как часто это делается, или как долго они могут занять.

В моей предыдущей организации FCA/PCA обычно выполнялся только как часть процесса выпуска продукта, и мы использовали ClearCase в качестве инструмента управления версиями с метками, наносимыми на всю кодовую базу для определения базовых показателей.У нас не было номеров версий во всех исходных файлах, а также не было номеров версий на всех экранах продуктов — деятельность CM выполнялась правильно и была подтверждена аудитами, и это никогда не было проблемой ни в одной оценке CMMI. .Мы могли бы использовать разницу между метками, чтобы посмотреть, какие файлы были изменены, выполнить различия, чтобы увидеть фактические изменения кода.Важной частью процесса является возможность связать эти изменения с требованием/отчетом об ошибке/с какой бы то ни было причиной, которая инициировала изменение.

В ходе нашего аудита использовались сценарии для автоматизации процесса, но это были сценарии, разработанные собственными силами и специфичные для ClearCase — в основном они перечисляли все файлы, их версии в системе CM и элемент базовой линии/конфигурации, к которому они принадлежали.

Answer 3

вы не можете использовать свой источник контроля для этого? если вы развертываете версию и помечаете свой sourcecontrol этим развертыванием, вы можете проверить ее с помощью системы контроля версий