DOing

2021.7.26~2021.8.1 MVP기능 까지 모두 완료되었다. 프론트와 연결을 해서 확인했다. 빡센 PR과정 당연하게 생각했던 것도 다시 생각하게 되었다 사람들이 이해되지않으면 코드를 merge시켜주지않으니 내가 왜 이렇게 짰는지 설명하는 시간이 많았다. 문제가 많이 발생하고 이를 어떻게 해결할지 토론 양방향 vs 단방향 FetchType Eager 패키징 구조에 대해서도 컨벤션이니까 .ok()를 다붙이자. 뭐 등등 많았다! 토론하는게 즐겁다 다같이 더 좋은 코드를 위해서 토론하는게 재밌다. 체력적으로 힘들긴하지만 그 과정이 정말재밌고 본받을 점이 많은 팀원들이라고 생각한다 나는 나만그런줄 알았는데 팀원들 전체가 그러고 있다. 어떻게 이렇게 팀을 짜놨지? 싶을 정도로 정말 코드에 대한 고민이 많은 ..

1. Github tokens 발급 2. Jenkins 토큰 3. token이 발급 완료 4. Jenkins Credentials 추가 secret에 github에서 발급받은 토큰을 넣어준다. 5. 만든 Credentials를 설정해주고 Test Connection 해준다. 6. 젠킨스 프로젝트를 만들기 하나의 프로젝트의 테스트, 빌드, 배포를 관리하기 위한 젠킨스 프로젝트를 만들어준다. 새로운 Item탭에 들어가 새로운 젠킨스 프로젝트를 만든다. 7. Github repository와 연동 8. 소스 코드 관리 설정 9. 소스 코드 관리 설정 - Credentials 10. 빌드 유발 11. 빌드시 사용될 Gradle에 대한 설정 Make gradlew executable을 체크하지 않으면 권한 에러로..

이전 포스팅에서는 EC2에 Jenkins를 설치했다면, 이번 포스팅에서는 설치한 Jenkins를 초기 설정을 해보려고 합니다. 1. 초기 패스워드 입력하기 2. 패스워드 가져오기 sudo cat /var/lib/jenkins/secrets/initialAdminPassword cat : 파일의 내용을 간단하게 출력할 때도 사용한다. 뿐만아니라 두 개 이상의 파일을 연결(concatenate)해서 출력할 때 사용한다. 보통 리다이렉션 기호와 함께 사용하여 파일을 생성하거나 병합을 할 때도 사용됩니다. 3. 플로그인 설정 4. 다 깔아지네..? 5. 사용자 계정 생성하고 로그인 이 계정 정보는 브라우저를 통해 Jenkins 접속시 항상 입력해야 함으로 꼭 잊어버리지 않아야 한다. 6. Jenkins 본격적으..

이번 포스팅에서는 EC2에 Jenkins를 설치해보겠습니다. Jenkins 공식문서를 보고 따라 적용하였습니다. 1. 자신의 EC2 인스턴스에 SSH로 접속한다. - 현재 나의 EC2 환경 : Ubuntu(18.04) 2. 젠킨스의 java 버전은 8버전이상 호환가능함으로 java 8버전을 설치한다. 3. Jenkins 리포지토리 키를 다운로드하여 설치한다. wget -q -O - https://pkg.jenkins.io/debian-stable/jenkins.io.key | sudo apt-key add - wget : 'Web Get'의 약어로 웹 상의 파일을 다운로드 받을 때 사용하는 명령어 젠킨스를 설치할 때, 파일들이 신뢰할 수 있는 소스로 부터 제공됨을 증명하기 위해 로컬 GPG 키링에 Jen..

항상 듣기만 했던 CI/CD에 대해서 이번에 공부를 해보려고 한다. 하나의 프로젝트를 끝까지 완료해보는 것도 좋은 경험이라는 말에 혹해서 공부해보기로 결심했다. 솔직히 말하면 프론트엔드 분들이 요청사항 추가할때마다 맨날 EC2들어가서 다시 배포하는게 너무 귀찮았다.. CI (Continuous Integration) 지속적 통합이란, 지속적으로 품질관리를 적용하는 프로세스를 실행하는 것이다. 고전적인 개발 프로세스는 개발을 완완료한 뒤에 품질 관리를 적용하는 방식이였다. 하지만 CI는 작은 작업단위의 작업에 품질 관리를 빈번하게 적용한다. 즉, 작은 기능들이 개발될 때마다 바로 빌드 및 테스트를 거쳐 공유 리포지토리에 병합한다. 하루에도 여러번씩 병합될 수 있다. CI의 장점은 오류를 빠르게 감지할 수 ..

이번 ActionPlan 팀프로젝트에서 제가 가장 고민했던 부분은 바로 '연관관계'였습니다. 제가 이전 개인 프로젝트에서 구현한 게시글과 댓글 CRUD는 사실 아무런 연관관계가 있지 않았습니다. 댓글에 직접 게시글 Id값을 넣고, 게시글 Id값으로 조회를 하였습니다. 이런 설계에 아쉬움을 느끼고 있었고 이번 팀프로젝트에서 연관관계 설정에 대해 팀원들과 고민하며 프로젝트에 적용시켰습니다. 그 과정에서 생겼던 이슈와 수정 과정, 제 생각의 변화에 대해 정리해보려고 합니다. 1차 시도) 양방향 실제 프로젝트 관련 PR 보러가기 : Github PR 링크 - Plan Entity @Entity public class Plan extends Timestamped { @Id @GeneratedValue privat..

➰ CASCADE (영속성 전이) : 특정 엔티티를 영속상태로 만들 때 연관된 엔티티들도 영속상태들로 만들고 싶을때 사용한다. : 주의해야 하는 것은 연관관계랑은 아무런 상관이 없다는 것이다.⭐⭐ : ALL(모두 적용) PERSIST(영속) REMOVE(삭제) 등이 있다. 이 세개만 주로 쓴다. : PERSIST -> 하위 엔티티까지 영속성 전달한다. -> 저장시 라이프사이클을 맞추고 싶을때 사용한다. 상위 엔터티 저장할때 하위 엔터티도 저장한다. : REMOVE -> 같이 삭제하고 싶을때 : ALL -> 라이프사이클을 디 맞춰야 할때 @Entity public class Parent{ @Id @GeneratedValue private Long id; @OneToMany(mappedBy="parent",..

⌚ 지연 로딩(FetchType.LAZY) @Entity public class Member { @Id @GeneratedValue private Long id; @Column(name = "USERNAME") private String name; @ManyToOne(fetch = FetchType.EAGER) // 지연로딩 : 프록시객체 @JoinColumn(name = "TEAM_ID") private Team team; .. } - Entity를 처음 생성할때 - 실제로 객체를 조회할때 Team team = member.getTeam(); team.getName(); // 실제 team을 사용하는 시점에 프록시 초기화 이때 쿼리가 나간다. 단순히 getTeam()으로 가져올 때가 아니고 team에 ..