Три значения слова «программа»
В техническом споре стороны нередко говорят об одном продукте, но представляют разные объекты. Заказчик показывает установленное приложение, разработчик — репозиторий, а в акте указан только номер версии. Эти материалы связаны, однако не взаимозаменяемы. До проверки полезно договориться, что именно будет называться версией, исходным комплектом и сборкой.
Версия обычно служит обозначением состояния продукта: например, «2.4» или «сентябрьский релиз». Она удобна для общения, но её точность зависит от принятого порядка выпуска. Одно обозначение может остаться прежним после повторной упаковки или срочного исправления. Поэтому рядом с названием версии фиксируют конкретные файлы и их идентификаторы.
Исходный комплект содержит текст программы и материалы, используемые для её получения: ресурсы, настройки проекта, сценарии сборки. Сборка — полученный результат, предназначенный для запуска, установки либо дальнейшей упаковки. Наличие исходников ещё не означает, что представленный установщик был собран именно из них.
Почему результат зависит не только от кода
На результат влияют используемые инструменты, зависимости, параметры и целевая платформа. В документации .NET отдельно описаны конфигурация сборки, архитектура, среда выполнения и восстановление зависимостей. Это конкретный пример того, почему фразы «исходники одинаковые» недостаточно для описания всей процедуры. Microsoft: dotnet build.
Также различайте собранный пакет и его развёртывание. Настройки сервера, содержимое базы и подключённые службы могут менять поведение без изменения основного кода. Если один экземпляр отправляет уведомления, а другой нет, сначала проверяют условия запуска, а не объявляют файлы разными программами.
В Git человекочитаемое обозначение может формироваться относительно доступной метки и положения коммита в истории. Само по себе такое обозначение не описывает весь внешний процесс сборки. Для исследования полезен полный идентификатор выбранного коммита и сведения о локальных изменениях. Git: git-describe.
Что означает воспроизводимая сборка
Проект Reproducible Builds связывает воспроизводимость с получением побитово одинаковых результатов при заданных исходниках, окружении и инструкциях. Это проверяемое техническое свойство процесса, а не следствие совпадения названия релиза. Reproducible Builds: определение.
Неудачная попытка получить идентичные файлы ещё не устанавливает подмену. Причиной могут быть незафиксированные зависимости, отличающиеся параметры или изменяющиеся служебные данные. Сначала описывают расхождение и исследуют его причину. Обратная ситуация тоже требует аккуратности: совпадение результатов не отвечает автоматически на вопрос о том, кто написал код.
Чек-лист идентификации версии
- Запишите название продукта и обозначение релиза, не ограничиваясь ими.
- Сохраните переданный установщик или пакет целиком, укажите контрольную сумму.
- Установите конкретное состояние исходников и отметьте изменения вне истории репозитория.
- Перечислите версии инструментов, зависимости, ресурсы и параметры сборки.
- Сохраните инструкцию, журнал сборки и перечень полученных файлов.
- Отдельно опишите конфигурацию развёртывания, тестовые данные и внешние службы.
- Укажите, какая связь подтверждена материалами, а какая пока предполагается.
Условный пример: два пакета с одинаковым номером
Предположим, заказчик и подрядчик передали установщики с надписью «3.1». Их контрольные суммы различаются. Это означает различие байтового содержимого пакетов, но ещё не объясняет его значение. Внутри могут отличаться рабочая библиотека, подпись пакета, ресурс или упаковочные данные.
Разумная последовательность — сравнить состав, выделить отличающиеся компоненты и проверить относящиеся к вопросу функции в одинаковой среде. Если проблема касается расчёта отчёта, различие изображения заставки не объяснит ошибку расчёта. Итог должен связывать конкретное отличие с конкретным наблюдением.
Как сформулировать результат без лишних обещаний
Полезный вывод звучит предметно: исследован пакет с указанной суммой; запуск выполнен в описанной среде; его связь с представленным состоянием исходников подтверждена такими-то материалами либо осталась непроверенной. Такой язык позволяет повторить проверку и не подменяет вопрос о работоспособности вопросом об идентичности файлов.
Технические источники
Следующий шаг
Применить к вашей задаче
Опишите объект, спорный период и то, что сохранилось. Уточним, какие вопросы можно проверить. Доступы и архивы передаются после согласования.
Обсудить задачу ↗Услуги и разборы по теме
- Экспертиза программного обеспечения ↗
- Экспертиза исходного кода ↗
- Какая версия была передана и что изменилось позже ↗
Ещё по теме
- Журнал Git в споре о разработке: что показывает история и чего не доказывает ↗
- Что передать для исследования программы: комплект материалов без лишних данных ↗
- Приёмка доработки 1С: как проверить результат на понятных сценариях ↗
Материал описывает техническую подготовку и не заменяет индивидуальное исследование или правовую консультацию.