programing

다중 배포 환경 (프로덕션 / 개발)에 Maven 사용

luckcodes 2021. 1. 16. 20:30

다중 배포 환경 (프로덕션 / 개발)에 Maven 사용


기본 디렉터리 구조를 사용하는 Maven에 웹 앱이 있습니다. 문제 없습니다. 기본 디렉토리 구조에는 내 localhost 데이터베이스를 가리키는 일부 속성 파일이 있습니다.

현재 저는 다음 명령을 사용하여 프로덕션 용과 개발 용으로 서로 다른 war 파일을 만드는 Ant 스크립트를 만듭니다.

ant deploy-dev
ant deploy-prod
ant deploy-sit
ant deploy-uat

그래서 기본적으로 그들은 전쟁 파일을 만든 다음 속성 파일을 연결하여 전쟁 파일을 업데이트합니다.

Maven에 그런 것이 있습니까 (구성에 따라 다른 전쟁이 생성됨)?

그렇다면 어떻게해야합니까?

나는 시도 mvn war했지만 전쟁을 만듭니다


참고 가장 좋은 방법입니다 하지 다른 환경에 대한 귀하의 유물을 다시해야 - 즉 재 생산-수있는 빌드로 이어질하지 않으며, 재건 할 때 다른 일을 잠재적으로 변화시킬 수있다. 즉, 위에서 제안한대로 리소스 필터링을 사용하면 프로젝트를 다시 빌드 할 때만 작동 합니다.

개발에서 테스트로 또는 승인 테스트에서 프로덕션으로 아티팩트를 졸업 할 때 다시 빌드 필요가 없습니다 .

원하는 것은 실제로 런타임 변수에 따라 동적 구성을 갖는 것입니다. 즉, 다른 환경에 대한 다른 스프링 설정 또는 속성 파일 예 :

db-dev.properties
db-test.properties
db-prod.properties

그런 다음 런타임 변수와 Spring의 PropertyPlaceholderConfigurer를 사용하여 이러한 구성간에 전환 할 수 있습니다 .

더 복잡한 설정을 위해 과거에했던 것처럼 실제로 다른 스프링 구성 파일을 사용할 수도 있습니다.

또한 '기본'설정을 프로덕션으로 두는 것이 좋습니다. 따라서 프로덕션에 배포하는 경우 환경 변수 설정을 잊어 버려도 걱정할 필요가 없습니다.


이 상황에서는 maven 프로필을 사용하는 것을 선호합니다. 예를 들어 디렉토리 구조가 있습니다.

src / 메인 / 리소스
|
+-지역
| |
| `-specific.properties
+-dev
   |
   `-specific.properties

pom.xml에서 두 개의 프로필을 정의합니다.

<profiles>
    <profile>
        <id>local</id>
        <activation>
            <activeByDefault>true</activeByDefault>
        </activation>
        <build>
            <resources>
                <resource>
                    <directory>src/main/resources/local</directory>
                </resource>
            </resources>
        </build>
    </profile>
    <profile>
        <id>dev</id>
        <build>
            <resources>
                <resource>
                    <directory>src/main/resources/dev</directory>
                </resource>
            </resources>
        </build>
    </profile>
</profiles>

이 경우 새 파일에 대해 pom.xml을 매번 업데이트 할 필요가 없습니다. IDE에서는 단순히 프로필을 전환하거나 명령 줄에서 -P 플래그를 사용합니다.

UPD : 구성에 대해 일부 속성이 동일한 경우 어떻게해야합니까? 다음과 같이 구성하십시오.

<profiles>
    <profile>
        <id>local</id>
        <activation>
            <activeByDefault>true</activeByDefault>
        </activation>
        <build>
            <resources>
                <resource>
                    <directory>src/main/resources</directory>
                </resource>
                <resource>
                    <directory>src/main/config/local</directory>
                </resource>
            </resources>
        </build>
    </profile>
    <profile>
        <id>dev</id>
        <build>
            <resources>
                <resource>
                    <directory>src/main/resources</directory>
                </resource>
                <resource>
                    <directory>src/main/config/dev</directory>
                </resource>
            </resources>
        </build>
    </profile>
</profiles>

공통 부분은에 저장 src/main/resources되고 다른 구성은 config 디렉토리의 적절한 폴더에 저장됩니다 .


프로세스에서 개미를 삭제하려면 필터가있는 빌드 프로필 사용을 살펴 보겠습니다.

이 시나리오에서는 속성 파일을 src / main / resources 트리 구조에 연결합니다. 그런 다음 다음과 같은 필터 속성을 사용하여 속성 파일을 매개 변수화합니다.

jdbc.url=${filtered.jdbc.property}

그런 다음 src / main / filters 내부에서 프로필을 기반으로 필터 파일을 만듭니다. 그래서 당신은 dev-filters.properties sit-filters.properties 등을 가질 수 있습니다. 여기에는 다음이 포함됩니다.

filtered.jdbc.property=jdbc url here

Then you setup build profiles for each region where you set an env property pointing to the particular region your building. You can then setup the resources filter to use ${env}-filters.properties for each build. Additionally, you can setup the war plugin to add the env property to your artifact so that you actually store 4 different artifacts in your repository under a different classifier.

You then simply build the app with each profile. You have to call the build for each profile, but it does work well.

Example of some settings in the POM:

<build>
  <filters>
    <filter>src/main/filters/filter-${env}-application.properties</filter>
  </filters>
  <resources>
    <resource>
      <directory>src/main/resources</directory>
      <filtering>true</filtering>
    </resource>
  </resources>
  <plugins>
    <plugin>
      <artifactId>maven-war-plugin</artifactId>
      <version>2.1-beta-1</version>
      <executions>
        <execution>
          <phase>package</phase>
          <goals>
            <goal>war</goal>
          </goals>
          <configuration>
            <classifier>${env}</classifier>
          </configuration>
        </execution>
      </executions>
    </plugin>
  </plugins>
</build>

<profiles>
  <profile>
    <id>LOCAL</id>
    <activation>
      <activeByDefault>true</activeByDefault>
    </activation>
    <properties>
      <env>LOCAL</env>
    </properties>
  </profile>
  <profile>
    <id>DEV</id>
    <properties>
      <env>DEV</env>
    </properties>
  </profile>
  <profile>
    <id>UAT</id>
    <properties>
      <env>UAT</env>
    </properties>
  </profile>
  <profile>
    <id>PROD</id>
    <properties>
      <env>PROD</env>
    </properties>
  </profile>
</profiles>

Also, props to this blog post which is where I originally found the steps to accomplish this.


I have handled this using Spring's PropertyPlaceholderConfigurer and including property files on the classpath and one on the filesystem:

<context:property-placeholder 
    location="classpath*:META-INF/spring/*.properties,file:myapp*.properties"/>

If there is a myapp*.properties file in the current directory when the app starts (or tests are run etc.) it will override properties from files baked into the war/ear/whatever.


There's this article about it on maven 2 using build profiles. It looks like it just delegates to ant anyways via the antrun plugin so you might even be able to get away with re-using your existing build.xml files.


This spells it out pretty well, uses the build profiles as @seth mentioned-

http://maven.apache.org/guides/mini/guide-building-for-different-environments.html


There is a plugin that helps simplifies some of this madness now.

https://environments-maven-plugin.sourceforge.io/index.html

Disclosure. I have authored the plugin.

ReferenceURL : https://stackoverflow.com/questions/1149352/using-maven-for-multiple-deployment-environment-production-development