Branch로 작업 후 Merge 하는 과정, GCP 인스턴스에 배포

LJH·2021년 7월 16일
0

DevOps 강의 (feat. Foo)

목록 보기
14/16

해당 내용은 Class101의 현직 대기업 개발자 푸와 함께하는 진짜 백엔드 시스템 실무! 강의를 기반으로 작성했습니다.

1. 목표

  • io bound 애플리케이션에 페이징, 검색 기능 개발

  • commit - push - PR - Mrege 과정 이해


2. 페이징 기능 구현

2-1. branch 따기

  • 새 기능을 개발하는 과정이다. sourcetree에서 우측 상단의 깃 플로우를 클릭하고
    새 기능 시작을 누르자.

2-2. 설정파일

  • 로컬에서 개발해야하기 때문에 datasource의 url을 localhost로 변경해줘야 한다.
    근데 매번 주석처리하면서 작업해야 하므로 번거롭다.

  • 이를 위해 profile 기능이 존재한다.

  • 패키징할 때 실제 운영환경과 개발 환경 설정파일을 선택할 수 있다.
    간단하니 자세한 내용은 이 글을 참고하자.

2-3. 기능 구현

@RestController
public class PostController {

    private static Integer PAGE_SIZE = 20;

    ...

    // 2. 글 목록 페이징 조회
    @GetMapping("/posts")
    public Page<Post> getPostList(@RequestParam(defaultValue = "1") Integer page) {
        return postRepository.findAll(
                PageRequest.of(page - 1, PAGE_SIZE, Sort.by("id").descending())
        );
    }

		...
}
  • 코드 설명은 jpa로 페이징 기능을 구현해봤다면 아는 내용이므로 생략한다.

  • postman으로 테스트해보면 정상적으로 나오는 걸 볼 수 있다.

2-4. Push

  • sourcetree를 이용한다. 이 때 yaml 즉 설정파일은 올리면안된다. 이전에 datasource의 url을 localhost로변경했기 때문이다.

  • 배포했을때는 이전에 생성한 PostgreSql의 인스턴스의 DB에 접근해야한다.

  • 커밋하자.

  • push를 해준다.

  • 이후에 paging 브랜치에서 개발한 기능을 develop 에 merge 할 것이다.

2-5. PR(Pull Request)

  • 레포로 오면 3분전에 push 이벤트가 발생했다는 메시지가 나온다.

  • Compage & pull request를 눌러보자.

  • 여기서 내 레포를 선택해줘야한다.

  • 이후 paging기능을 develop 브랜치에 Merge할 것이기 때문에 base를 develop으로 변경해준다.

  • Assignees를 본인 계정으로 바꿔준다.

  • PR 이후 상단에 Files changed를 클릭해보면 코드에서 삭제한 부분과, 추가된 부분이 한 파일에 나타나게 된다. 가독성이 떨어지므로 설정에서 Split으로 변경해준다.

  • 그럼 위와같이 두 개의 파일로 분할되어 편하게 볼 수 있다.

2-6. Merge

  • 다시 Conversation 탭으로 돌아와서 Merge pull request를 해주자.

  • Merge 전략에는 세 가지전략으로 나뉘는데 선택은 팀바팀이라고 한다.

  • 나는 Rebase and Merge를 수행한다.

  • sourcetree로 돌아와 pull 하게 되면 paging 기능 구현이 origin/develop에 반영된 걸 볼수있다.

  • 현재 위치를 develop으로 옮기게 되면 로컬과 origin에서 발생한 차이때문에 이상하게 나온다.
  • 따라서 pull해주면 된다.

3. 글 번호로 검색 기능 구현

  • 마찬가지로 develop에서 새 기능을 추가한다. (새 브랜치를 딴다.)

3-1. 기능 구현 후 테스트

// 3. 글 번호로 조회
@GetMapping("/post/{id}")
public Post getPostById(@PathVariable("id") Long id){
    return postRepository.findById(id).get();
}

  • 정상 동작 확인

3-2. PR 후 Merge

  • 과정은 위와 동일하다. Merge 후 소스트리에서 pull 해보면 위와 같이 나온다.

4. 글 내용으로 검색기능 구현

  • 마찬가지로 새 브랜치를 따고 코드를 추가한다.
// PostController
// 4. 글 내용으로 검색 -> 해당 내용이 포함된 모든 글
@GetMapping("/search")
public List<Post> findPostBycontent(@RequestParam String content){
    return postRepository.findByContentContains(content);
}

---

// PostRepository
@Repository
public interface PostRepository extends JpaRepository<Post, Long> {
    List<Post> findByContentContains(String content);
}

  • 이후 테스트해보면 정상 동작하는 걸 볼 수 있다.

  • PR 날리고 Merge 후 로컬에서 pull 하면 위와 같은 화면이 나왔을 것이다.

5. 메인 브랜치로 병합

  • 현재까지는 필요한 기능들을 새 브랜치에서 개발하고 develop 브랜치에 Merge했다.

  • 이제 모든 기능을 구현 했으니 main 브랜치에 병합해보자.

  • 이후 push까지 해주고 이제 GCP 인스턴스에 배포하면 된다.

6. GCP 인스턴스에 배포

  • Jenkins를 이용해 배포한다. 이전 글에서 만들어둔 아이템을 이용해 빌드한다.

  • 빌드 로그에 Succeess가 뜬걸 보고 Nginx ip로 요청을 날려보았는데 아래와 같은 화면이 나왔다.

  • 이전에도 본적이 있는 화면이다. Nginx 로드밸런싱 설정할 때 봤다.

  • 이 글에서 확인할 수 있다. 이 때는 rule이 없어서 발생하는 문제엿고 sudo setsebool -P httpd_can_network_connect on 명령어를 통해 해결할 수 있었지만 이번에는 해결되지 않았다.

  • 당연히 Nginx 서버가 문제라고 생각했지만 워커 인스턴스에러 로그를 확인하고 찾아보니
    워커 인스턴스에서 돌아가는 애플리케이션에서 응답이 오지않아 Nginx가 저런 에러를 뱉는거라고 한다. 그래서 다시 젠킨스를 빌드해서 배포하니까 정상적으로 동작했다.


7. 마무리

  • 이번에 진행한 내용들은 아래와 같다.

    1. 브랜치 따서 글 목록을 페이징하는 기능 & 글을 조회하는 기능 추가
    2. main 브랜치에 병합 후 젠킨스를 이용해 GCP 인스턴스에 배포
  • 다음에는 해당 애플리케이션을 스트레스 테스트 해 볼 것이다.

0개의 댓글