땃쥐네

보통 프로젝트를 진행하다보면 A -> B -> C -> D -> E 와 같은 의존방향의 코드는 자주 작성됩니다. 이렇게 의존성의 방향을 알 수 있으면 뭐를 고쳐야할지 잘 보일거에요. 근데 의존성의 방향을 잘 못 관리한다거나, 계층을 넘어 의존하는 코드를 작성하면서 관리하다보면 위 그림처럼 B에서 E를 강하게 의존한 코드를 작성하게 되는 일이 생기고(특히 테스트 코드), E가 변경되면 D 뿐만 아니라 B의 코드를 변경하게 되는 일이 빈번하게 발생합니다. 무엇이 무엇을 의존하는지, 의존성의 방향은 어떤지 통제하기 힘들어지면 향후 코드 관리가 점점 힘들어집니다.  외부 모듈들을 테스트를 해보고 싶은데 모두 끌어와서 실행해야한다는 점도 저를 귀찮게 하는게 많았습니다.이메일 발송 라이브러리가 잘 작동되는 지 확인..

이번 글에서는브랜치가 푸시될 때마다 프로젝트 작업물이 EC2에 무중단으로 배포될 수 있도록 해보겠습니다.1. GitHub Actions 에 DockerHub / EC2 접근 자격증명 부여이전 글에서 지속적 통합을 GitHub Actions 를 통해 했듯, 지속적 배포 역시 GitHub Actions 를 통해 수행할 것입니다. 그런데 이전 글에서는 DockerHub, EC2 에 접근하는 작업을 하지 않았지만 이번에는 접근하는 작업을 해야합니다.제 DockerHub 에 도커 이미지를 push 한다거나, EC2 에 SSH 에 접속한다거나 하는 작업에 있어서는 몇 가지 자격증명이 필요합니다. 이것들을 우선적으로 준비해보겠습니다.  1.1 [GitHub Actions] DockerHub 액세스 토큰 준비  Git..

이전 글에서 AWS 전반적인 인프라 환경을 구성했습니다. 이번에는 프로젝트를 생성하고,풀리퀘스트에 커밋이 올라올 때마다 빌드테스트가 자동화되도록 하겠습니다.1. 스프링부트 프로젝트 생성, Git - GitHub - Jira 연동 프로젝트를 생성해보겠습니다. 일단은 간단하게 프로젝트를 생성하고, 구조를 바꿀 일이 있다면 이후 글에서 바꾸도록 하겠습니다. 이번 글에서는 배포 자동화에 초점을 맞추고 있기 때문에 복잡한 설정은 하지 않을겁니다. 1.1 스프링부트 프로젝트 생성 Intellij Ultimate 를 쓴다면 Spring Boot Initializr 지원 기능이 있으므로 그걸 써도 됩니다.근데 그렇지 않은 분들이 더 많은 것 같고 웹의 Spring Initializr 로 프로젝트를 생성했습니다.저는 자..

일단 프로젝트는 대충 어떤 기능을 구현할 지 정했는데, 이것을 어디에 배포할 지가 문제입니다.취준생 입장에서 비싼 돈을 지불해가면서 서비스를 배포하는 것은 감당이 안 되는 지라 AWS 프리티어 기능을 사용하기로 했습니다. AWS 프리티어는 1년동안 일정 사용량 내에서 기능을 무료로 사용할 수 있기 때문에 취준생 입장에서 사용하는데 큰 부담이 안 되더라구요.  일단 배포 기본 아이디어는 VPC 를 준비하고, 퍼블릭 서브넷에 EC2 를 한 대 둔 뒤EC2 내에 Nginx(도커 컨테이너)를 통해 들어오는 요청을 뒤의 스프링 서버(도커 컨테이너)로 포워딩 시키는 방식을 사용할 생각입니다.  첫번째로 구현할 스토리, 백엔드 인프라 구성(AWS EC2) 입니다. 대강 이 작업이 어떤 가치가 있는 지, 이 작업이 만..

백엔드의 기본기가 되는 게시판을 구현해보기로 했습니다. 화면 구현도 생각해봤는데, 백엔드 시스템 하나 구현하기도 생각보다 할게 많아서 백엔드 API 에 집중하기로 했어요.정말 여유가 생기면 프론트엔드 구현도 고려해볼 생각입니다.  게시판을 막상 구현하라고 하면 뭘 구현해야할지 감이 안 서서, 현재 시중에 유명한 커뮤니티 사이트 몇 군데를 찾아봤습니다. 네이버 카페, FM 코리아, 아카라이브, 디시인사이드, ...그 외에도 SNS 서비스인 인스타그램, 페이스북, 트위터 등등도 유명합니다.각각의 사이트의 구조를 겉에서 확인해보고 공통적인 것을 약간씩 추려내면서 기능을 간단하게 나마 기획해봤습니다.   어떤 기능이 있으면 좋겠다, 라는 간단한 생각에서 시작하여 이 기능은 어떤 흐름으로 구현될 것인지,어떤 방식..