기록들 https://github.com/ndgndg91

Spring Boot 와 RDBMS 환경에서 개발하면서 Test 를 작성할 때, 테스트 환경의 경우 주로 H2 를 사용한다. H2 는 몇 줄만 추가해주면 Test 환경에서 사용이 가능하기 때문에 설정이 매우 쉽다. 하지만 production 환경에서는 MySQL, PostgreSQL, MS SQL, Oracle 등 H2 와는 다른 Database 를 사용하고 있다면 이슈가 발생할 수 있다. 기본적으로 지원되는 문법이 다르거나 Database Engine 이 동작하는 방식이 달라서 Test 를 신뢰할 수 없다. 이것은 본질적으로 Test Code 를 작성하는 의미를 지키기 힘들어진다. H2 에서 compatible 모드를 지원하지만 본질적으로 완전하게 동일한 환경을 보장할 수 없다.  아래 링크를 통해서 확인할 수 있다. http://www.h2database.com/html/features.html#compatibility 모든 database engine 들은 조금씩 다르게 동작합니다. H2 는 ANSI 표준을 지원하고 다른 database 와 호환되도록 노력합니다. 하지만 여전히 차이가 존재합니다. https://www.h2database.com/html/advanced.html#acid 또한, Transaction 도 다르게 동작한다. ACID 의 개념을 빠뜨릴 수 없는데  MySQL 의 경우 default Isolation Level 은 REPEATABLE READ 이지만 H2 default Isolation Level 은 READ COMMITED 이다. Phantom Read 이슈가 발생하게 된다.  물론 설정을 REPEATABLE READ 로 변경하고 Production 환경과 최대한 비슷하게 설정하고나서 H2 사용을 고려해 볼 수 있다. 하지만, 쉽게 설정할 수 있다는 H2 의 장점이 없어진다. 따라서 Production 환경과 최대한 동일한 환경으로 쉽고 빠르게 설정하여 테스트를 진행할 수 있도록 TestContaine...

 GitOps 를 구현하는 과정에서 고민했었던 부분 그리고 해결한 방법을 정리하려고 한다. GitOps 에서 크게 Application Repository ( Code Repository ) 와 Environment Repository ( State Repository ) 두 가지의 Repository 로 정의가 된다. 조직의 프로세스나 크기, 형태, 철학마다 다르겠지만, 일반적인 회사에서나 어떤 프로젝트에서 협업을 할 때 보통 개발팀과 운영팀이라는 개념으로 나뉠 수 있을 것이다. 이 때 보통 Application Repository 는 개발팀이 Environment Repository 는 운영팀이 관리할 것이다. 개발팀에서 지속적으로 새로운 기능 및 유지 보수를 진행함에 따라서 소프트웨어의 변경이 일어난다. 해당 변경은 CI 를 통해서 새로운 Container Image 를 생산할 것이다. 이 때 운영팀은 Image 들의 버전을 Environment Repository 에 반영해야 한다.  이 과정에서 여러가지 의문점이 들었다. 운영팀은 Environment Repository 의 Application 들의 버전 변경을 수동으로 반영할까 자동으로 반영할까? 수동으로 반영하는 프로세스라면 휴먼에러가 발생하지 않을까? 발생한다면 어떻게 대처할까? 자동으로 반영한다면 그것또한 무결함을 보장할 수 있을까? 이러한 의문점들은 귀결은 "Environment Repository 를 어떻게 관리하는게 좋을까?" 이다. 조금만 생각해보면 해당 질문에 정답이 있는것은 아니라는 결론이다. 모든것은 현재 해당 프로젝트 해당 조직이 처한 context 에 따라 다를것이다. 규모가 큰 조직일수록 관리해야할 application 이 많아서 수동으로 관리하는 것에 한계를 느낄 것이고, 반대로 규모가 작은 조직일수록 수가 적은 application 들을 관리하기 위해서 자동화를 하는 것에 더 비용을 크게 느낄수 도 있을 것이다.  개인적으로 자동화는 단기적인 관점...