- рассказ (несчастный случай)
- субсреда
- Подсреда для достижения
- Недостатки указания упаковки среды
- только один пакет
- управление веткой git
- проверка версии
- git-commit-id-plugin
- Адрес проверки версии
- Суммировать
- связанные ресурсы
DevOps — это сочетание разработки и эксплуатации.Как инженер-программист или системный архитектор, вы должны иметь полное представление и контроль над разработкой и развертыванием системы.
Далее мы расскажем вам решение конфигурации подсреды и проверки версии в выпуске программного обеспечения через историю...
Весь код, задействованный в этой статье, можно найти здесь 👉maven-devopsПолучать.
рассказ (несчастный случай)
Представьте себе сценарий, в котором вы создаете функцию: Заходите в определенную систему каждый день в 4 утра, чтобы получить электронное письмо с данными, а затем отправьте его своему боссу в виде электронного письма в 6 утра следующего дня.
Сначала вы разрабатываете и тестируете на своем компьютере, а после подтверждения завершения разработки упаковываете код, размещаете его на тестовом сервере и запускаете.
Вы найдете милую сестру-испытателя, которая проходит тщательное тестирование и подтверждает, что прошла все тесты. Наконец, вы не забываете похвалить тестируемую младшую сестру за то, что волосы у нее действительно красивые, и неявно говорите, что если у вас есть время, вы хотите пригласить ее посмотреть недавно вышедший фильм Marvel. (На самом деле у младшей сестры волосы не завиты, и она не поняла ваших намеков. Она не любит смотреть фильмы Марвел. Самое главное, что у вас совсем нет времени приглашать других смотреть фильмы - этот вопрос. Просто задайте носки, которые уже две недели спокойно лежат в вашей стиральной машине.)
Вы объединяете свой код с основной веткой, а затем уведомляете издателя о выпуске кода в рабочую среду. Когда вы получите уведомление от эксплуатационного и обслуживающего персонала о том, что разблокировка прошла успешно, посмотрите на часы, а сейчас два часа ночи. Выпили кофе из чистой чашки, глубоко расслабились и поехали домой.
Наутро вас разбудил взрыв быстрого телефонного звонка, а голос на другом конце телефона навеял сонливость: начальник не получал писем, а информация в письмах будет на важной встрече Через 2 часа использования!
......
Данные, наконец, есть, но усталость, страх, стыд и самообвинение захлестнули ваш разум, и вы собираетесь что-то сделать: найти причину и исправить ее навсегда!
Отличие глупого человека от мудрого в том, что глупый человек будет только падать, а мудрый после падения встанет, не забыв засыпать яму, а также поставит рядом с собой памятник, чтобы предостеречь будущее. поколений-- На данный момент это почти великий человек.
субсреда
Как упоминалось ранее, есть три среды для разработки, тестирования для тестовой сестры и выпуска для эксплуатационного и обслуживающего персонала.На самом деле, среда программной системы часто больше, чем они.
Обычно используемые среды: dev, sit, uat, sandbox, pro.
-
dev — это среда разработки.Каждый разработчик создает среду самостоятельно.Конечно, некоторые распространенные службы среды разработки, такие как базы данных и распределенные службы, обычно строятся на внутренних серверах компании.
-
sit — это среда тестирования системной интеграции (System Integration Testing Environment), основной целью которой является тестирование различных модулей системы как группы.
-
uat — это Среда приемочного тестирования пользователей (User Acceptance Testing Environment), которая обычно является средой для людей, знакомых с системой, для принятия результатов разработки.
-
Песочница — это среда песочницы, которая представляет собой наиболее реалистичную симуляцию производственной среды.
-
Pro — это производственная среда, в которой работает наш конечный продукт.
Почему так много сред? Ответ вынуждается обстоятельствами. При все более тонком разделении труда в разработке программного обеспечения и возрастающей сложности программных систем разные среды несут разные обязанности, но конечная цель одна и та же: повышение эффективности, обеспечение качества, снижение затрат и обеспечение прибыли.
Я не буду здесь много говорить об идее подокружений.Следующий вопрос — как реализовать подокружения?
Существует множество способов реализации различных сред: Spring Profile, Spring Boot и т. д. имеют разные реализации.
Давайте поговорим о способе использования профилей maven для реализации конфигурации подсреды.
Реализация по среде
Например, мне нужно предоставить разные файлы конфигурации в разных средах, как этого добиться?
Сначала добавьте конфигурацию следующих сред в pom.xml и укажите путь к конфигурации:
<profiles>
<!-- 分环境profile> -->
<profile>
<id>dev</id>
<!-- 如果dev带上activeByDefault，会默认将dev下的配置复制到config目录下-->
<activation>
<activeByDefault>true</activeByDefault>
</activation>
<properties>
<env>dev</env>
<package.target>dev</package.target>
<spring.profiles.active.value>dev</spring.profiles.active.value>
<yui.skip>true</yui.skip>
<config.path>src/main/resources/config/dev</config.path>
</properties>
</profile>
<!--sit-->
<profile>
<id>sit</id>
<properties>
<env>sit</env>
<package.target>sit</package.target>
<spring.profiles.active.value>sit</spring.profiles.active.value>
<yui.skip>false</yui.skip>
<config.path>src/main/resources/config/sit</config.path>
</properties>
</profile>
<!-- uat -->
<profile>
<id>uat</id>
<properties>
<env>uat</env>
<package.target>uat</package.target>
<spring.profiles.active.value>uat</spring.profiles.active.value>
<yui.skip>false</yui.skip>
<config.path>src/main/resources/config/uat</config.path>
</properties>
</profile>
<!--sandbox-->
<profile>
<id>sandbox</id>
<properties>
<env>sandbox</env>
<package.target>sandbox</package.target>
<spring.profiles.active.value>sandbox</spring.profiles.active.value>
<yui.skip>false</yui.skip>
<config.path>src/main/resources/config/sandbox</config.path>
</properties>
</profile>
<!--prod-->
<profile>
<id>prod</id>
<properties>
<env>prod</env>
<package.target>prod</package.target>
<spring.profiles.active.value>prod</spring.profiles.active.value>
<yui.skip>false</yui.skip>
<config.path>src/main/resources/config/prod</config.path>
</properties>
</profile>
</profiles>
Затем при упаковке проекта передайте-PПараметр указывает среду. Например, чтобы упаковать среду uat:
$ mvn install -Puat
Недостатки указания упаковки среды
Первый медленный, или пустая трата кофе. Многие крупные проекты каждый раз занимают более получаса от компиляции до извлечения файлов.
Так как же нам сэкономить время на публикации и позволить нам уйти с работы раньше? Ответ — один пакет для всех сред.
5 сред могут сэкономить 2 часа, так что оно того стоит!
только один пакет
Как насчет одного пакета для всех сред?
Сначала настройте в pom.xmlmaven-resources-pluginплагин и указатьcopy-resourcesПуть ко всей конфигурации среды указан в файле package.
<!-- maven-resources-plugin -->
<plugin>
<artifactId>maven-resources-plugin</artifactId>
<version>2.6</version>
<executions>
<execution>
<id>copy-resources</id>
<phase>validate</phase>
<goals>
<goal>copy-resources</goal>
</goals>
<configuration>
<outputDirectory>${basedir}/target/classes/config</outputDirectory>
<resources>
<resource>
<directory>${config.path}/</directory>
<filtering>true</filtering>
</resource>
</resources>
</configuration>
</execution>
</executions>
</plugin>
затем используйте как обычноmvn installПакет.
Наконец, после копирования пакета для публикации на диск указанной машины среды, перейдитеmvКоманда для настройки среды должна быть опубликована для выхода. Такие как издательская среда песочницы:
mv config/sandbox/* config/
Конечно, эта операция необязательна, например, вы указываете текущую среду при запуске контейнера, а затем передаете${spring.profile.active}Также можно указать конфигурацию, в которой каталог читается в данный момент.
управление веткой git
В соответствии с различными пакетами для каждой среды выпуск новой функции в рабочую среду требует процесса, подобного следующему:
- Сначала используйте ветку разработки для упаковки, выпуска среды сидя и слияния теста с веткой выпуска;
- Затем используйте ветку выпуска для упаковки, опубликуйте ее в среде uat и объедините с основной веткой для тестирования (пометки);
- Наконец, упакуйте его с основной веткой и выпустите в производственную среду. Разработчики могут изменять код только в ветке разработки и ветке функций, а основная ветка согласуется с кодом, работающим онлайн.
После выпуска пакета во все среды режим управления ветвями будет изменен на:
- После успешного самотестирования функции в функциональной ветке код вливается в релизную ветку, а тестировщики тестируют в релизной ветке и, наконец, выпускают ее для производства.
- Когда код будет успешно выпущен в рабочую среду, объедините код ветки релиза с основной веткой.
Рисунок выше демонстрирует多环境多包发布а также多环境单包发布Кратко процесс выглядит следующим образом.
Выпуск нескольких пакетов для нескольких сред
- Каждая среда упаковывается и выпускается отдельно до тех пор, пока все тесты среды не передают окончательный выпуск в рабочую среду.
- Наконец, объедините код основной ветки с веткой разработки, чтобы убедиться, что код ветки разработки совместим с онлайн-кодом.
Выпуск одного пакета для нескольких сред
- Сделайте пакет только в ветке выпуска для публикации во всех средах. Если обнаружена ошибка, она будет переупакована до тех пор, пока не будут проверены все ошибки.
- После того, как пакет, использующий ветку релиза, будет успешно выпущен, код ветки релиза будет объединен с основной веткой для резервного копирования, что удобно для исправления в будущем.
- Наконец, объедините код основной ветки с веткой разработки, чтобы убедиться, что код ветки разработки совместим с онлайн-кодом.
проверка версии
Теперь проблема медленной упаковки решена, но как сделать так, чтобы версия кода, выпущенная эксплуатационным и обслуживающим персоналом, соответствовала версии, в которой находится наша функция?
Конечно, на словах можно подтвердить, что описанная выше «трагедия» произошла в результате.
Так мы можем проверить сами? Затем используйте инструменты.
git-commit-id-plugin
git-commit-id-pluginэто плагин, который будет генерировать плагин на основе номера версии текущей веткиgit.propertiesдокумент.
Во-первых, введите конфигурацию плагина в pom.xml:
<!-- https://github.com/git-commit-id/maven-git-commit-id-plugin -->
<plugin>
<groupId>pl.project13.maven</groupId>
<artifactId>git-commit-id-plugin</artifactId>
<version>${git-commit-id-plugin.version}</version>
<executions>
<execution>
<id>get-the-git-infos</id>
<goals>
<goal>revision</goal>
</goals>
</execution>
</executions>
<configuration>
<!-- 使properties扩展到整个maven bulid 周期, Ref: https://github.com/ktoso/maven-git-commit-id-plugin/issues/280 -->
<injectAllReactorProjects>true</injectAllReactorProjects>
<dateFormat>yyyy.MM.dd HH:mm:ss</dateFormat>
<verbose>true</verbose>
<!-- 是否生 git.properties 属性文件 -->
<generateGitPropertiesFile>true</generateGitPropertiesFile>
<!--git描述配置,可选;由JGit提供实现; -->
<gitDescribe>
<!--是否生成描述属性 -->
<skip>false</skip>
<!--提交操作未发现tag时,仅打印提交操作ID -->
<always>false</always>
<!--提交操作ID显式字符长度,最大值为:40;默认值:7; 0代表特殊意义;-->
<abbrev>7</abbrev>
<!--构建触发时,代码有修改时(即"dirty state"),添加指定后缀;默认值:""; -->
<dirty>-dirty</dirty>
<forceLongFormat>false</forceLongFormat>
</gitDescribe>
</configuration>
</plugin>
Затем упакуйте проект, вы можете видеть, что в вашем скомпилированном файле есть еще один файл.git.propertiesдокумент:
#Generated by Git-Commit-Id-Plugin
#Sat Apr 20 13:08:01 CST 2019
git.branch=master
git.build.host=DESKTOP-12GT5DQ
git.build.time=2019.04.20 13\:08\:01
git.build.user.email=ijiangtao@foxmail.com
git.build.user.name=ijiangtao
git.build.version=1.1.01.01-SNAPSHOT
git.closest.tag.commit.count=
git.closest.tag.name=
git.commit.id=67b60eeffa9deca877c2b9a28d52a40d3ea55444
git.commit.id.abbrev=67b60ee
git.commit.id.describe=67b60ee
git.commit.id.describe-short=67b60ee
git.commit.message.full=\u53D1\u9001\u91CD\u8981\u6570\u636E\u7ED9\u8001\u677F~~~~
git.commit.message.short=\u53D1\u9001\u91CD\u8981\u6570\u636E\u7ED9\u8001\u677F~~~~
git.commit.time=2019.04.20 12\:57\:50
git.commit.user.email=ijiangtao@foxmail.com
git.commit.user.name=ijiangtao
git.dirty=false
git.remote.origin.url=https\://github.com/javastudydemo/jsd-maven.git
git.tags=
git.total.commit.count=2
С помощью этого файла мы можем четко знать, какая версия кода находится в производственной среде.
Важно отметить, что при использовании этого подключаемого модуля убедитесь, что проект, который вы компилируете, имеет каталог .git, поскольку этому подключаемому модулю необходимо получить информацию о коммите git.Если вы не используете git для управления версиями проекта компиляция сообщит об ошибке.
Адрес проверки версии
Ниже приведен контроллер для отображения информации о коммите git.
package net.ijiangtao.tech.maven.web.controller;
import com.alibaba.fastjson.JSON;
import com.alibaba.fastjson.serializer.SerializerFeature;
import com.wordnik.swagger.annotations.Api;
import com.wordnik.swagger.annotations.ApiOperation;
import org.springframework.stereotype.Controller;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.ResponseBody;
import java.util.*;
import static org.apache.commons.lang3.ObjectUtils.defaultIfNull;
/**
* @author ijiangtao
*/
@Controller
@Api(value = "", description = "git info from git-commit-id-plugin")
public class GitCommitController {
/**
* @return
*/
@RequestMapping("/git/commit/info")
@ResponseBody
@ApiOperation(value = "get commit info", httpMethod = "GET")
public String showGitCommitInfo() {
//git.properties
ResourceBundle resourceBundle = ResourceBundle.getBundle("git", defaultIfNull(null, Locale.getDefault()));
Map<String, String> map = new TreeMap<>();
Enumeration<String> keysEnumeration = resourceBundle.getKeys();
while (keysEnumeration.hasMoreElements()) {
String key = keysEnumeration.nextElement();
map.put(key, resourceBundle.getString(key));
}
return JSON.toJSONString(map, SerializerFeature.PrettyFormat);
}
/**
* @return
*/
@ApiOperation(value = "get commit id", httpMethod = "GET")
@RequestMapping("/git/commit/id")
@ResponseBody
public String showGitCommitId() {
//git.properties
ResourceBundle resourceBundle = ResourceBundle.getBundle("git", defaultIfNull(null, Locale.getDefault()));
return resourceBundle.getString("git.commit.id");
}
}
Запустите проект с плагином Jetty и получите доступSwaggerUIадресhttp://localhost:8241/swagger/index.html, наконец черезhttp://localhost:8241/git/commit/infoЗапрос ушел в наш коммит git.
Как правило, для удобства отката версии мы упаковываем ее через git commit id при публикации, и мы можем сравнить их с помощью машины для достижения цели автоматической проверки, вместо того, чтобы каждый раз требовать ручной проверки.
Суммировать
В этой статье объясняется способ реализации использования Maven для настройки среды и проверки версии выпуска, что очень полезно в практике непрерывной интеграции/непрерывного развертывания (CI/CD).