본문으로 건너뛰기

자바 개발 환경 및 절차

실질적인 백엔드 개발 환경 구축에 대한 내용과 코드 분석 및 관리, 이슈 처리등 전반적인 절차를 설명 드립니다.

로컬 개발환경 구성​

코드베이스 복제​

깃랩에서 해당되는 소스 코드 저장소로 이동합니다. (할당되지 않은 저장소에는 접근 할 수 없습니다.)

프로젝트ID저장소
상담어드바이저ADV/ccaas/adv/service-adv‎ ‎ ‎ ‎ ‎ /ccaas/adv/ui-adv
콜봇CB/ccaas/cb/service-cb‎ ‎ ‎ ‎ ‎ /ccaas/cb/ui-cb
대화엔진CE/ccaas/ce/service-ce‎ ‎ ‎ ‎ ‎ /ccaas/ce/ui-ce
지식관리시스템KMS/ccaas/kms/service-kms‎ ‎ ‎ ‎ ‎ /ccaas/kms/ui-kms
품질평가QA/ccaas/qa/service-qa‎ ‎ ‎ ‎ ‎ /ccaas/qa/ui-qa
상담분석TA/ccaas/ta/service-ta‎ ‎ ‎ ‎ ‎ /ccaas/ta/ui-ta

사용하시는 git 클라이언트 도구를 활용 하시거나 git 명령으로 clone 합니다.

정보

아래 명령의 {project-id} 는 각 담당 프로젝트의 id로 치환 해야 합니다.

git clone https://haiv.timbel.net:48443/ccaas/{project-id}/service-{project-id}

cd service-{project-id}

README.md​

복제된 소스 코드에서 README.md 파일의 내용을 숙지하세요.

주의

내용 안에서 실행 섹션에 있는 부분을 실행해 주세요. 복제된 소스 코드가 로컬에서 정상 작동되는지 확인 한 후에 다음 단계로 넘어가야 합니다.
명령실행 로그의 마지막 부분에

[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------

와 같이 성공을 확인 하세요.

Checkstyle 플러그인​

우리 개발 환경에서는 코드 스타일에 checkstyle이 필수 구성 됩니다. 따라서 코드가 구성에 맞지 않을 경우, 소스 병합을 위한 commit 자체가 원천 차단하기 때문에 로컬 환경에서 플러그인을 통해 미리 확인 하시면 번거로움을 줄일 수 있습니다.

  1. checkstyle - https://plugins.jetbrains.com/plugin/1065-checkstyle-idea를 통해 플러그인 설치

  2. settings 에서 checkstyle 을 검색한 후 스냅샷과 같이 설정

    https://raw.githubusercontent.com/timbel-net/maven-plugins-start-with-langsa/initialize/src/main/resources/checkstyle.xml

  3. 플러그인 패널에서 rules 를 선택하고, ▶️ 실행버튼으로 현재 열려있는 파일에 대해서 검증

Sonarlint (Sonarqube) IDE 플러그인​

우리 개발 환경에서는 정적코드분석에 sonarqube이 필수 구성 됩니다. 따라서 코드가 구성에 맞지 않을 경우, 정적코드분석에 의한 이슈 수정 요청이 있을 수 있으니 로컬 환경에서 플러그인을 통해 미리 확인하시면 번거로움을 줄일 수 있습니다.

  1. 설치

  2. Sonarqube 설정

    • Settings 에서 "sonarlint" 을 검색
    • Connection Name && SonarQube URL 입력 
      https://static-analysis.langsa.ai

    • 토큰 인증 방식 선택 후 Create token 클릭
    • 로그인(깃랩) 후 이미지 버튼 처럼 Allow connection 선택


    • Apply 하여 적용

  3. 플러그인 패널에서 ▶️ 실행버튼으로 현재 열려있는 파일에 대해서 검증

개발 시나리오​

업무 확인​

슬랙을 통해 전달 받은 기획서에서 업무 분장된 내용을 확인하세요.

feats-* 브랜치​

개발 시작하기 전에 git origin 에서 Fetch(or Pull)을 실행하고, main 브랜치 기준으로 새로운 feats-* 브랜치를 생성합니다.

커밋​

시작하기 - 커밋 메세지 포맷에서 자세히 확인할 수 있습니다.

팁

커밋 주기는 짧게 진행 하시기 바랍니다. 예를들면, 각 레이어 별로 커밋을 하거나 코드 파일 하나를 기준으로 커밋하시는 것을 추천 드립니다.

푸시​

  • 충돌 상황은 적절히 코드를 살피고 당사자와 조율해서 해결 하세요.
  • feats-* 나 fixed-* 기준에 맞추지 않은 브렌치 이름은 푸시가 안돼요.
  • 푸시 상황은 슬랙으로 통보 됩니다.

이슈​

  • 깃랩으로 이슈가 작성되고, 슬랙으로 통보 됩니다.
  • 이슈를 확인하고 정리한 후 반드시 Close 해주세요.
커밋 메세지에 다음과 같은 내용으로 쉽게 Close 할 수 있습니다.

✨ 기능수정
오류로 접수된 내용을 수정한 상세 설명 close #12

위와 같은 close #12 키워드가 메세지에 포함되면 12번 이슈가 close 됩니다.
뿐만 아니라 fix #12, fixed #12, issue #12, resolve #12 등등도 동일하게 동작 합니다.

fixed-* 브랜치​

기능 개발이 완료 된 후에, 이슈가 등록 되면 fixed-* 브랜치를 생성해서 이슈를 처리하는 코드를 작성합니다.
이후 절차는 시나리오의 시작부터 반복 진행 합니다.

정적코드분석 (Sonarqube)​

정적코드분석 도구에서 자세히 확인할 수 있습니다.

CI/CD (Jenkins)​

푸시가 발생되면 Maintainer 권한자가 main 브랜치로 병합을 실행하고, 그때 배포 프로세스가 진행됩니다.
배포 결과도 슬랙으로 통보 됩니다.