[Devops/회고]Section 1. 실습과제

Summary

• 간단하지만 시간이 촉박하다 3일의 시간이 주어지지만 2.5일 느낌
• 기능과 코드의 퀄리티를 높이기 보다는 협업을 중점을 두고 팀원들과 작업하였다
• 미숙한 git 사용법으로 충돌 에러를 많이 보았지만, 경험을 많이 쌓을 수 있었던 거 같기도…
• 설계는 어렵다…🥴

---

시작한지 얼마 안된 것 같은데 벌써 한달의 시간이 지나가고 있고
첫 번째 프로젝트가 끝났습니다.

• 리눅스 운영체제
• 웹서비스 개발 기초
• Git
• HTTP
• WEB / WAS Server
• 데이터베이스

한달의 시간이 훅 빠져나간 이유인 공부주제들...(많기도 하다🤮)

부트캠프를 수강하기도 전에도 계속 공부해오던 내용이라 적응하는 것에 중점을 둬서 공부했었다. 몰랐던 내용도 알게 되며 아직은 여유가 있었다고 느꼈다

---

첫 실습 프로젝트

어떤 이유에선지 모르나 어찌저찌 팀장이 되었고, Section1. 프로젝트가 시작되었다.
프로젝트의 주제는 쇼핑몰로 정해졌다

실습 목표

실습의 중요한 목적은 다음과 같다

• API 설계 및 문서를 작성 한다.
• 관계형 데이터베이스를 위한 데이터 모델링을 한다.
• Git 을 이용한 협업을 진행한다.

제작 범위 및 기술 스택

• Javascript
• Fastify
• PostgreSQL
  - ElephantSQL 이용
• ERD 제작
• API 문서 제작

목표는 최소한의 CRUD 기능을 가진 한개의 API 서버를 만드는 것이다. 목표 자체는 그렇게 어렵지 않은 내용이라고 생각하고 나는 중점을 설계와 협업으로 눈을 돌리고 팀원과 작업을 진행하였다.

개발이 끝나고 API 를 사용한 결과 화면

ISSUE

작업을 끝내고 push 하는데에 문제가 생겼다.

힌트 문구를 보았을 때 내 local 과 remote 가 맞지 않기 때문에 git pull 작업을 하고 다시 시도해 보라고 유도해 주고 있다. 작업하던 내용들을 잃어 버리면 안되기에 git stash 로 임시 저장하고 git pull 을 해보았는데…

git pull 조차 안된다. 하지만 치명적인 에러는 아니고 자세히 읽어 보면 설정을 해달라는 말인데.

git pull 방식을 정해 달라는 것이다. .

• 기존 pull
  • 불필요한 merge commit 이 생성 아래 그림의 빨간색 부분
  • 3-way merge 와 비슷하다.
• git pull --ff-only
  • fast-forward 관계일 때만 pull을 허용한다.
  • fast-forwad 관계는?
    • 로컬저장소에만 새로운 commit이 있고, 원격저장소에는 없다.
    • 원격저장소에만 새로운 commit이 있고, 로컬저장소에는 없다.
• git pull --rebase
  • 새 브랜치가 시작된 분기점 commit이 존재한다. 이 분기점을 기준 브랜치의 가장 최근 commit으로 변경하는 작업.
  • 로컬 브랜치의 시작점을 원격 브랜치의 마지막 commit으로 옮기는 식인 것 같다. 그 과정에서 conflict가 발생할 경우 이를 해결해줘야 할 듯 싶다.
  • git history가 깔끔해진다는 장점이 있지만, 부주의하게 사용할 경우 별도의 알림 없이 git history를 영구적으로 변경할 수 있기 때문에 ff-only 방식을 더 추천한다고 한다.

git config pull.ff only

위 세가지 방식중 ff 방싱이 추천되므로 명령어로 pull 방식 설정해 주고 다시 실행하였지만

fast-forwad 가 가능하지 않고 중단되었다고 나온다!

강제 PULL

수정 파일 보다 local 의 상태를 conflict 되기 전인 수정 전으로 되돌려야 할거 같아 이번 한 번은 강제적인 방법을 사용하였습니다.

git fetch --all
git reset --hard personal/main
git pull personal main

명령을 통해 수정전 상태로 돌리고 수정파일을 가져온뒤 재 push 하여 해결하였습니다.

강제를 하는 방법이므로 좋은 방법은 아니라고 생각합니다.
가장 좋은 방법은 conflict 된 파일을 찾아서 수정하여 push 를 하거나 stash 를 적극 활용하는 것이 가장 좋은 방법을 아닐까 싶습니다.

마치며

Java 의 SpringBoot 환경에서 공부하던 나에게 생각보다 처음이 많았다.

API 문서를 위한 도구를 사용해보기도 하고,
PostgreSQL 을 처음 써보기도 하며

• PostgresSQL 은 마음에 들었다. 조금씩 다른 부분이 있으나 RETURNING 이 있다는게 마음에 들었는지 Postgres 를 향한 첫 인상은 굉장이 좋았다 🤗

Fastify 프레임워크를 처음 다뤄봤다.

• javascript 생태계 답게 굉장히 가볍고 간편한 느낌이 있다. 하지만 처음 사용하는 것이고, 실제 개발 단계는 1일에 가까워서 기능들을 다 활용하지는 못하는 것이 아쉬웠다. Javascript 언어를 잘 알지 못한다는 점도 한 몫했다.(ES6 도 한번은 공부해서 정리하는 게 좋지 않나 하고 생각이 들었다🤔)

처음으로 협업을 하게 되었다.

• 이전에도 같이 협업을 한 경우도 없잖아 있지만, 뭔가 인정하고 싶지 않은 결과물이나 작업이 매우 tiny 한 경우 였기에 이렇게 온전히 팀원들이 있고 git 을 사용해서 협업한 경우는 없기에 감격스러운 정도...😭
• 어떨결에 팀장을 하게 되었지만, 믿음직하지 못한 팀장을 잘 따라와준 팀원들에거 무한한 감사의 박수를 전합니다 👏👏👏

다짐

다음 Section2. 는 Devops 영역의 발을 디딛는 것과 같은 주제들로 짜여있기에 집중해서 Section2 를 진행할 생각이다. 주제들을 듣기만 해도 너무 기대된다. 조금만 적어보자면

• Docker
• AWS
• CI/CD

한 번씩 다 해보았지만 전문적으로 교육을 받아본적이 없이 어깨너머 배워왔던 입장이라 너무 두근두근하다. 잘 배워서 잘 써먹어야지😎