SpringBoot 버전을 업그레이드 해야할 일이 생겨서 2.3 버전을 2.5 버전으로 업그레이드한 경험담을 공유합니다.

개발인생 처음으로 해보는 레거시 시스템의 프레임워크 업그레이드 작업이었습니다.

대부분은 신규 프로젝트를 만들거나 deprecate 된 상태로 유지하는 정도였죠.

그래도 해보고 싶었던 부분이었습니다. 업무가 많이 지루해진것도 한 몫 했죠.

저는 주기적으로 반기에 한번정도는 라이브러리 업그레이드 작업을 진행해야한다고 생각하지만

저희 개발팀은 이상하게 라이브러리 업그레이드 작업을 안합니다. 

그런데 갑자기 프레임워크 업그레이드를 하려니 dependency 가 많이 걸려있을거라 예상했죠.

우선 2.3 -> 2.4 로 올라가면서 어떤 부분에 변화가 생겼는지를 확인하고 대응하고,

2.4 -> 2.5 에서는 어떤 변화가 있었는지 확인하여 대응하면 될거라 생각했고 

아래 2개의 spring boot release note 를 하나하나 살펴봤습니다.

• Upgrade from 2.3 to 2.4
• Upgrade from 2.4 to 2.5

2.3 -> 2.4 에서 변경된 부분

• JUnit 5’s Vintage Engine Removed from spring-boot-starter-test
• Config File Processing (application properties and YAML files)
• Config Data Imports
• Embedded database detection
• User-defined MongoClientSettings no longer customized
• Logback Configuration Properties
• Default Servlet Registration
• HTTP traces no longer include cookie headers by default
• Undertow Path on Forward
• Neo4j
• Hazelcast 4
• Elasticsearch RestClient
• R2DBC
• Flyway
• Removal of Plugin Management for Flatten Maven Plugin
• Version management for exec-maven-plugin
• Spring Boot Gradle Plugin
• Metrics export in integration tests
• Deprecations from Spring Boot 2.2 and 2.3

2.4 -> 2.5 에서 변경된 부분

• SQL Script DataSource Initialization
• Flyway and Liquibase JDBC URLs
• Spring Data JPA
• Spring Data Solr
• Secure Info Endpoint
• Task Scheduling Harmonization with Spring Integration
• Default Expression Language (EL) Implementation
• Messages in the Default Error View
• Logging Shutdown Hooks
• Gradle Default jar and war Tasks
• Cassandra Throttling Properties
• Customizing jOOQ’s DefaultConfiguration
• Groovy 3
• Minimum Requirements Changes
• Hibernate Validator 6.2

위에 나온 내용 이외에도 업그레이드 되면서 deprecated 되는 것들에 대한 부분들, 그리고 새로 추가 된 부분들에 대한 설명을 하나하나 읽어보고 현재 내가 담당하는 프로젝트에서 사용되는 것들과 연관된 것들을 모두 읽어보았습니다.

그리고 spring boot 버전을 변경한 뒤 오류가 발생하는 부분은 없는지 배포는 잘 되는지를 확인했습니다.

boot 업그레이드 작업하면서 변경했던 부분은 아래 내용들이었습니다.

• spring.config.use-legacy-processing = true 설정을 추가
• fasterxml.jackson.databind.PropertyNamingStrategy -> PropertyNamingStrategies 클래스 변경
• third-party dependency 들 중에서 업그레이드가 필요한 것들 확인 및 업그레이드
• gradle 버전 업그레이드 6.7 -> 6.9

작업 내용만보면 진짜 별거 아니었던 작업으로 보이네요. 작업시간보다 문서 읽어보는 시간이 더 오래 걸렸던것 같습니다. 링크를 타고타고 들어가야 확인할 수 있는 것들이 많다보니..

아무튼 로컬환경에서 잘 돌아가는 것까지 확인 하고 개발에 올려 테스트를 해보니 애플리케이션이 정상적으로 실행되지 못하는 현상이 확인되었습니다. 왜 그런가 봤더니 jar 파일명이 이상하게 바뀌어있었습니다. 끝에 -plain postfix가 붙은 파일명이 배포된 것을 확인했고 이게 뭔가 싶어 구글링을 해보니 release note 에서 설명을 찾아볼 수 없었지만(내가 못 본 걸수도?) 2.5버전부터 발생하는 현상이었고 gradle 설정에서 jar task를 비활성화 시키거나 배포파일을 만드는 task 에서 해당 파일을 exclude 처리하면 되는 문제였습니다.

매일 반복되는 특별하지 않은 업무들만 하다가 처음으로 해본 프레임워크 업그레이드 작업은 너무 재미있었고 좋은 경험이었습니다.

내년에는 java 17 + SpringBoot 3 기반의 신규 프로젝트를 하나 만들어야 하는데 벌써부터 기대되고 현재 사용중인 java 11 에서 17까지 어떤 변화들이 있었는지 확인하는 시간을 가져야 할 것 같습니다.

출처 : http://docs.oracle.com/cd/E11882_01/server.112/e10819/intro.htm#BHCHIAFE

번역 : TexasCowboy 

Moving From Standard Edition to Enterprise Edition of Oracle Database

If you have Oracle Database Standard Edition at a release earlier than the new Oracle Database 11g release, then you can change it to Oracle Database Enterprise Edition by installing Oracle Enterprise Edition software and subsequently following the normal upgrade procedures, as described in Chapter 3, "Upgrading to the New Release of Oracle Database.".

To change your existing Standard Edition database to an Enterprise Edition database 

1. Ensure that the release number of your Standard Edition server software is the same release as Enterprise Edition server software.
   사용중인 스탠다드 에디션 릴리즈 번호와 설치하려는 엔터프라이즈 에디션 릴리즈 번호가 동일한지 확인해라. ( 동일하지 않으면 안된다. )

   For example, if your Standard Edition server software is release 11.1.0.6, then you must upgrade to release 11.1.0.6 of Enterprise Edition.
    

2. Shut down your database.
   데이타베이스를 중지시킨다.
    

3. If your operating system is Windows, then stop all Oracle services, including the OracleServiceSID Oracle service, where SID is the instance name.
   윈도우 운영체제를 사용중이라면 OracleServiceSID Oracle Service를 포함한 모든 오라클 서비스를 중지시켜야 한다.
    

4. Make a backup copy of files under $Oracle_Home/network/admin. This ensures that the listener is configured after you complete the steps in this procedure.
   $Oracle_Home/network/admin 폴더 안에 백업파일을 넣는다.
    

5. Back up all database files and data under the current Oracle home that you need to keep.

   • On Linux, back up $Oracle_Home/dbs/.

   • On Windows, back up $Oracle_Home/database/.

    

   
   DB파일을 모두 백업한다.
    

    

6. Edit the orabase_cleanup.lst file found in the Oracle_Home/utl directory and remove the "oradata" and "admin" entries. Refer to "Deinstallation of the Oracle home in the earlier release of Oracle Database may result in the deletion of the old Oracle base that was associated with it".
   Oracle_Home/utl 디렉토리 안에있는 orabase_cleanup.lst 파일을 수정해서 oradata와 admin 부분을 지워준다.
    

7. Deinstall the Standard Edition server software.

   Run the deinstall tool from the Oracle home. The deinstall tool is located in the $ORACLE_HOME/deinstall directory for UNIX platforms, and in the ORACLE_HOME\deinstall directory for Windows platforms.

   IMPORTANT:

   The deinstall tool deletes all existing database files that reside under Oracle home, including data in the database. Therefore, Oracle recommends that you retain a current backup of your data.
   스탠다드 에디션을 deinstall한다. Oracle Home디렉토리 안에 deinstall디렉토리가 있고 그 안에서 deinstall실행파일을 찾을 수 있을 것이다. deinstall명령은 현존하는 Oracle Home밑의 모든 DB파일과 데이타를 삭제하므로 백업을 해두는 것이 좋을 것이다.
    

8. Install Enterprise Edition server software using Oracle Universal Installer (OUI).

   Select the same Oracle home that was used for the Standard Edition that you uninstalled. During the installation, be sure to select Enterprise Edition. When prompted, choose Software Only from the Database Configuration screen.
   OUI를 이용해서 엔터프라이즈 에디션을 설치한다. 스탠다드 에디션이 사용했던 Oracle Home과 동일한 경로를 Oracle Home으로 지정한다.
    

9. Start up your database.
   데이타베이스를 시작한다.

Your database is now upgraded to Enterprise Edition.

Known Issue with the Deinstallation Tool for Release 11.2.0.4

Deinstallation of the Oracle home in the earlier release of Oracle Database may result in the deletion of the old Oracle base that was associated with it

Cause: After upgrading from Oracle Database release 11.2.0.1 or 11.2.0.2 to release 11.2.0.4, deinstallation of the Oracle home in the earlier release of Oracle Database may result in the deletion of the old Oracle base that was associated with it. This may also result in the deletion of data files, audit files, etc., which are stored under the old Oracle base. Important Note: This issue is applicable for upgrades from release 11.2.0.1 or 11.2.0.2 to 11.2.0.4, but is not applicable for upgrading from release 11.2.0.3 to 11.2.0.4.

Action: Before deinstalling the Oracle home in the earlier release, edit the orabase_cleanup.lst file found in the $Oracle_Home/utl directory and remove the "oradata" and "admin" entries. Then proceed with the deinstallation.