Как Вы генерируете информацию о версии?
Я использую их для многократного использования моих классов объектной модели. У меня есть набор классов, которые представляют объекты, которые я имею в базе данных. Эти классы используются в стороне клиента только для отображения объектов, таким образом, основное использование получает доступ к свойствам.
public class Stock {
public Code { get; private set; }
public Name { get; private set; }
}
Из-за того шаблона использования я не хочу иметь методы бизнес-логики в этих классах, таким образом, я делаю каждую бизнес-логику, чтобы быть дополнительным методом.
public static class StockExtender {
public static List GetQuotesByDate(this Stock s, DateTime date)
{...}
}
Этот путь я могу использовать те же классы для обработки бизнес-логики и для пользовательского интерфейса, отображающегося, не перегружая сторону клиента с ненужным кодом.
Одна интересная вещь об этом решении случается так, что мои классы объектной модели являются динамическим сгенерированным использованием Моно. Cecil, таким образом, было бы очень трудно добавить методы бизнес-логики, даже если бы я хотел. У меня есть компилятор, который читает файлы определения XML, и генерируйте эти классы тупиков, представляющие некоторый объект, который я имею в базе данных. Единственный подход в этом случае должен расширить их.
5 ответов
Обычно такие вещи выполняются с помощью программного обеспечения для отслеживания проблем. Вы отслеживаете каждую новую функцию, каждое исправление и каждое улучшение, назначаете их выпуску, а затем генерируете примечания к выпуску на основе описаний.
В моей компании мы используем bugzilla. Мы используем веху, чтобы пометить ошибку конкретным номером версии. Затем мы генерируем xml-отчет для всех ошибок с определенным этапом и используем небольшой скрипт для генерации примечаний к выпуску на его основе.
Это то, что можно легко обобщить для любого программного обеспечения для отслеживания ошибок в целом.
Я полагаю, это также может быть связано с комментариями в сообщениях коммитов в вашей системе контроля версий. Можно сделать запрос, чтобы перечислить все комментарии к коммитам в элементе управления версоном, а затем отфильтровать все комментарии с помощью определенного тега.
Предполагая, что разработчики не являются частниками и являются частью команды, которая получает задания и выполняет их, список того, что было сделано и что должно быть частью UAT, является фактическим примечанием к выпуску. Списки изменений файлов и тому подобное не имеют отношения к делу и могут быть легко извлечены из системы управления версиями.
Поскольку очень сложно обеспечить соблюдение политики разработчиков, проверяющих код с номерами проблем в нем, я не беспокоюсь. Я спрашиваю об этом при проверке кода. Еще я веду список того, над чем мы работаем. То, что сделано-сделано, добавляется в журнал прямо перед запуском команды mvn release: prepare. Затем я перехожу к QA и UAT.
Маловероятно, что число выпусков в неделю достигнет сотен. В таких случаях более надежная система, вероятно, будет предпочтительнее.
Для этого можно использовать такой инструмент, как doxygen, но комментировать то, что ожидает doxygen, довольно утомительно. Обычно я беру их вручную.
Не уверен, но разве что-то вроде FogBugz не сделает то же самое?
If you are using maven, there is a the maven changes plugin for this purpose and producing this report could thus be easily automated in an continuous integration process.