<aside> 💡 앞으로 빈번히 있을 ES에 대한 개발 과정을 통일된 양식으로 정리하여 추후에 개발 인력이 들어왔을 때, 개발 규칙 및 주의점을 정리하도록 하자
</aside>
local_dev_prod_feature/search_indexes[/optional]의 형태로 브랜치를 만들어서 개발 진행
옵션 부분은 error와 같이 특수한 상황에서 들어가며 전반적인 index나 search(api)에 대한 부분은 사용하지 않도록 하자
feature의 경우는 신중하게 개발 환경에서 충분히 테스트를 거치고 머지를 시키도록 하자 → 기본적으로 개발 환경에서 브랜치를 전환하여 테스트를 진행하도록하자
테스트가 완료되었다면 squash와 delete branch를 꼭 하도록 하자 → 깔끔하고 롤백상황이 생겼을 때, 유용하게 쓰일 수 있다.
도큐먼트의 구조가 바뀌는 상황에서는 reindex.sh을 이용한 안전한 자동화를 통해서 배포를 하도록 하자
플러그인 적용의 경우는 Elastic Cloud에서 ES 인스턴스를 리부팅해야하는 문제가 생길 수 있다. 시간이 꽤나 소요되는 작업이기 때무에 플러그인의 설치는 매우 신중해야 한다.
[x] 플러그인을 다운로드 하는 과정에서 서치 api가 제대로 동작을 하는가?
개발 서버에서 적극 테스팅을 시도해볼 필요가 있다.
→ 현재 트라이얼 모드로 인해서 플러그인 서치 불가능
→ ⭐3개의 클러스터가 있기 때문에 문제없이 작동한다...⭐
[x] 다중 노드 설정으로 api의 호출이 가능하다면 아침시간에 플러그인을 업데이트 하는 것으로!
[x] 아니라면은 코너랑 상의해보는 것으로...
정상적으로 작동을 하기 때문에 문제없이 진행 완료 하였다!
버전 문제
형재 사용하고 있는 elasticsearch의 버전과 플러그인의 버전을 맞추어야 한다.
→ 오픈 소스마다 전용 버전이 있기 때문에 빌드 전에 elasticsearch 버전을 수정하여 적용하도록 하자! (버전이 맞지 않으면 elasticsearch 클러스터에 추가하지 못한다.)
빌드 옵션 문제
gradle을 좀 더 공부해야 알겠지만, elasticsearch가 원하는 방식의 .zip 파일을 올려야 한다!
→ 깃헙의 가이드 라인을 잘 따라가도록 하자!
젠킨스로 빌드를 하면서 자동으로 search-index 명령어를 실행하도록 할 수 있을까?
→ git diff를 통해서 document 파일이 변경되었다면 자동으로 실행을 하도록 할 수 있을 것이다.