Microsoft раньше поддерживала файл с именем BuildInfo.config, который был полезен для такого рода вещей, но я думаю, что поддержка для него была прекращена после Visual Studio 2015.
По сути, это был простой XML-файл, созданный MSBuild. При развертывании вместе с двоичными файлами приложения среда ведения журналов может считывать файл и включать подробности в выходные данные журнала.
Существует множество способов создать подобную функцию самостоятельно. Вот что я бы сделал ...
- Создайте пустой файл информации о сборке и зарегистрируйте его с вашим исходным кодом. Этот файл является просто справочным примером - используйте данные заполнителя. Это может быть XML, JSON или любой другой формат (но, вероятно, должен быть основан на тексте). Установите для файла действие сборки значение «Содержимое», чтобы он был включен в выходные данные сборки.
- Используйте функцию инициализации шаблона или инициализации телеметрии, чтобы прочитать файл информации о сборке и включить его содержимое в вывод журнала. Точная реализация будет зависеть от вашей среды ведения журналов.
- Добавьте задачу сценария Powershell в свой конвейер разработки Azure. Сценарий должен либо обновить, либо перезаписать файл информации о сборке. Вы можете получить некоторую полезную информацию из переменных построения . Задача должна быть запущена до этапа компиляции MSBuild.
Создание и анализ файла BuildInfo
В этом примере я собираюсь реализовать свой файл информации о сборке как простой ключ / значение
пары в текстовом файле. Я выбрал простой текст, потому что он позволяет наглядный пример
не требуя каких-либо сторонних библиотек или сложного разбора. В вашем приложении вы
Возможно, вы захотите использовать JSON, XML или что-то еще более стандартизированное.
Сначала создайте файл информации о сборке-заполнителе. Этот файл будет использоваться в вашем
локальная среда разработки, и будет служить ссылкой для вашей информационной схемы сборки.
Я назвал мой BuildInfo.txt и поместил его в корневой каталог моего проекта.
COMMIT=commit not set
BUILD=build not set
Затем напишите помощника для анализа файла информации о сборке. Моя очень зачаточная. Это
было бы разумно добавить некоторые средства защиты от отсутствующей или искаженной информации о сборке, но
Я решил опустить любой защитный код, чтобы пример был сфокусирован.
class BuildInfo
{
// Singleton instance backing field
static readonly Lazy<BuildInfo> instance = new Lazy<BuildInfo>(() => new BuildInfo());
// Singleton instance public accessor
public static BuildInfo Instance => instance.Value;
public string Commit { get; }
public string Build { get; }
private BuildInfo()
{
// This is a very rudimentary example of parsing the info file. It
// will fail loudly on malformed input. Consider:
// 1) Using a standard file format (JSON, XML). I rolled my own
// here to avoid adding a dependency on a parsing library.
// 2) If you want your app to fail when no build info is
// available, add a more descriptive exception. If you don't
// want it to fail, add some devensive code or fallback logic.
var info = File.ReadAllLines("BuildInfo.txt")
.Select(l => l.Split('=', 2))
.ToDictionary(key => key[0], val => val[1]);
Commit = info["COMMIT"];
Build = info["BUILD"];
}
}
Добавить информацию о сборке к вашему выводу журнала
Я использую log4net здесь, но любая структура логирования должна иметь несколько похожих
механизм настройки вывода журнала. Обратитесь к документации по структуре для
больше информации.
Сначала добавьте информацию о вашей сборке в контекст регистрации. Это должно пойти где-то в
Код запуска вашего приложения - как можно раньше.
log4net.GlobalContext.Properties["Build"] = BuildInfo.Instance.Build;
log4net.GlobalContext.Properties["Commit"] = BuildInfo.Instance.Commit;
Затем обновите конфигурацию приложения журнала, чтобы включить настраиваемые поля.
Вот пример конфигурации для консольного приложения. Важные биты
%property{BuildId} и %property{Commit}.
<?xml version="1.0" encoding="utf-8" ?>
<log4net>
<appender name="ConsoleAppender" type="log4net.Appender.ConsoleAppender">
<target value="Console.Error" />
<layout type="log4net.Layout.PatternLayout">
<conversionPattern value="%-5level [%property{BuildId}] [%property{Commit}] - %message%newline" />
</layout>
</appender>
<root>
<level value="ALL"/>
<appender-ref ref="ConsoleAppender" />
</root>
</log4net>
Теперь, когда вы позвоните log.Warn("Some log mesage"), вы увидите следующее
консольный вывод:
WARN [build not set] [commit not set] - Some log mesage
Получить детали сборки от CI
Наконец, вам нужно получить реальные подробности сборки из вашей среды CI. я сделал
это с очень простой задачей скрипта PowerShell. Убедитесь, что задача выполняется до
ваш шаг сборки!
@(
"COMMIT=$($Env:BUILD_SOURCEVERSION)",
"BUILD=$($Env:BUILD_BUILDID)"
) | Out-File BuildInfo.txt
(Совет. Чтобы просмотреть все доступные переменные среды, запустите Get-ChildItem Env: | Sort Name в задаче PowerShell)
(Еще один совет: если вы хотите использовать JSON вместо текста, взгляните на командлет ConvertTo-Json)
Теперь, если все части на месте, сервер CI должен перезаписать
зарегистрированный файл информации о сборке. Новый файл должен быть пакетами с вашим
развертываемые артефакты и копируются на ваш сервер. При запуске ваше приложение должно
прочитайте информацию о сборке, и затем информация должна быть включена в каждое сообщение журнала.
Между сборкой и развертыванием нужно выстроить множество мелочей
процесс, так что будьте готовы к некоторым пробам и ошибкам. Настройка CI / CD имеет тенденцию быть
утомительно, по моему опыту.