Сборка и Нумерация Версии для Проектов Java (муравей, cvs, Гудзон)
Тестирование в классе - неправильный способ, предупреждение о том, что если ваш код правильно определен, то this не должно быть нулевым, поэтому тест должен выполняться в тот момент, когда вы вызываете функцию-член: [ 117]
int main()
{
ExampleClass* myClass = nullptr; // always initialize a raw pointer to ensure
// that it does not point to a random address
// ....
if (myClass != nullptr) {
myClass->readSomeData(2.5);
}
return 0;
}
Если указатель не должен быть нулевым в определенной части вашего кода, вы должны сделать это в соответствии с CppCoreGuideline: I.12: Объявить указатель, который не должен быть нулевым, как not_null [115 ]
Micorosoft предоставляет библиотеку поддержки руководящих принципов , которая имеет реализацию для not_null.
Или, если возможно, тогда вообще не используйте указатели, кроме std::optional.
Таким образом, настройка кода может выглядеть следующим образом:
#include
struct ExampleClass {
void readSomeData(double ){}
};
// now it is clear that myClass must not and can not be null within work_with_class
// it still could hold an invalid pointe, but thats another problem
void work_with_class(gsl::not_null myClass) {
myClass->readSomeData(2.5);
}
int main()
{
ExampleClass* myClass = nullptr; // always initialize a raw pointer to ensure
// that it does not point to a random address
// ....
work_with_class(myClass);
return 0;
}
7 ответов
Для нескольких из моих проектов я получаю число пересмотра подверсии, время, пользователь, который выполнил сборку и некоторую информацию о системе, наполняет их в .properties файл, который включен в банку приложения, и считайте ту банку во времени выполнения.
Код муравья похож на это:
<!-- software revision number -->
<property name="version" value="1.23"/>
<target name="buildinfo">
<tstamp>
<format property="builtat" pattern="MM/dd/yyyy hh:mm aa" timezone="America/New_York"/>
</tstamp>
<exec executable="svnversion" outputproperty="svnversion"/>
<exec executable="whoami" outputproperty="whoami"/>
<exec executable="uname" outputproperty="buildsystem"><arg value="-a"/></exec>
<propertyfile file="path/to/project.properties"
comment="This file is automatically generated - DO NOT EDIT">
<entry key="buildtime" value="${builtat}"/>
<entry key="build" value="${svnversion}"/>
<entry key="builder" value="${whoami}"/>
<entry key="version" value="${version}"/>
<entry key="system" value="${buildsystem}"/>
</propertyfile>
</target>
Просто расширить это для включения безотносительно информации, которую Вы могли бы хотеть добавить.
Программное обеспечение:
- SVN
- Муравей
- Гудзон, для непрерывной интеграции
- svntask, задача Ant для нахождения пересмотра SVN: http://code.google.com/p/svntask/
Гудзон имеет три сборки/задания: Непрерывный, Ночью и Выпуск.
Для Непрерывной/Ночной сборки: Номер сборки является пересмотром SVN, найденным использованием svntask.
Для Сборки конечных версий / задание: Номером сборки является Номер выпуска, читайте Муравьем из файла Свойств. Файл свойств может также быть распределен с выпуском для отображения номера сборки во времени выполнения.
Сценарий сборки Муравья помещает номер сборки в файл манифеста файлов банки/войны, которые создаются во время сборки. Относится ко всем сборкам.
Действие постсборки для Сборок конечных версий, сделанных легко использование Гудзонского плагина: отметьте SVN с номером сборки.
Преимущества:
- Для dev версии банки/войны разработчик может найти пересмотр SVN от банки/войны и искать соответствующий код в SVN
- Для выпуска пересмотр SVN является тем, соответствующим тегу SVN, который имеет номер выпуска в нем.
Надеюсь, это поможет.
Я использую Гудзон также, хотя намного больше более простого сценария:
Мой скрипт Ant имеет цель в нем, которая похожа:
<target name="build-number">
<property environment="env" />
<echo append="false" file="${build.dir}/build-number.txt">Build: ${env.BUILD_TAG}, Id: ${env.BUILD_ID}, URL: ${env.HUDSON_URL}</echo>
</target>
Гудзон устанавливает эти переменные среды для меня каждый раз, когда мои прогоны задания.
В моем случае этот проект является веб-приложением, и я включаю это build-number.txt файл в корневой папке веб-приложения - я действительно не забочусь, кто видит его.
Мы не отмечаем управление исходным кодом, когда это сделано, потому что нам уже настроили наше Гудзонское задание для меток его с номером сборки / метка времени, когда сборка успешна.
Мое решение только покрывает возрастающие номера сборки для разработки, мы не стали достаточно далекими в проекте, где мы покрываем номера выпуска все же.
- Номера сборки должны быть связаны с непрерывным сервером интеграции как Гудзон. Используйте различные задания для различных ответвлений/команд/дистрибутивов.
- Для хранения номера версии в заключительной сборке я рекомендовал бы просто использовать знатока для системы сборки. Это создаст .properties файл, заархивированный в финал .jar/.war/.whatever-ar на
META-INF/maven/<project group>/<project id>/pom.properties. .properties файл будет содержать свойство версии. - Так как я рекомендую знатоку, я убедил бы Вас проверить плагин выпуска, чтобы подготовить выпуск на исходном репозитории и сохранить версии на синхронизации.
Мы работаем, наша сборка через CruiseControl (введите своего любимого менеджера по сборке здесь), и выполните основную сборку и тесты.
Мы затем увеличиваем номер версии с помощью Муравья и BuildNumber и создаем файл свойств с этой информацией плюс дата сборки и других метаданных.
Нам выделили класс чтению этого и если это к графический интерфейсам пользователя/журналам и т.д.
Мы затем упаковываем все это и создаем развертываемую связь вместе номер сборки и соответствующая сборка. Все наши серверы выводят эту meta информацию о запуске. Мы можем возвратиться через журналы CruiseControl и связать номер сборки с датой и checkins.
Вот мои 2 цента:
Мой сценарий сборки создает номер сборки (с меткой времени!) каждый раз я создаю приложение. Это создает слишком много чисел, но никогда лишь немногих. Если у меня будет изменение в коде, то номер сборки изменится, по крайней мере, однажды.
Я присваиваю версию номеру сборки с каждым выпуском (хотя не промежуточный). Когда я обновляю проект, и я получаю новый номер сборки (потому что кто-то еще сделал выпуск), я перезаписываю свою локальную версию и запускаюсь. Это может привести к более низкому номеру сборки, который является, почему я включал метку времени.
Когда выпуск происходит, номер сборки фиксируется, поскольку последний объект в единственной фиксации с сообщением "создает 1547". После этого, когда это - официальный выпуск, целое дерево отмечено. Таким образом, файл типа "build" всегда имеет все теги и существует простое 1:1 отображающийся между тегами и номерами сборки.
[РЕДАКТИРОВАНИЕ] я развертываю version.html со своими проектами и затем, я могу использовать скребок для простого сбора точной карты, что установлено где. Если Вы используете Tomcat или подобные, вставляете номер сборки и устанавливаете метку времени description элемент web.xml.Помните: Никогда ничего не запоминайте, когда у Вас может быть компьютер, делают это для Вас.
Ваш Build.xml
...
<property name="version" value="1.0"/>
...
<target name="jar" depends="compile">
<buildnumber file="build.num"/>
<manifest file="MANIFEST.MF">
...
<attribute name="Main-Class" value="MyClass"/>
<attribute name="Implementation-Version" value="${version}.${build.number}"/>
...
</manifest>
</target>
...
Ваш код Java
String ver = MyClass.class.getPackage().getImplementationVersion();