| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | ||
| 6 | 7 | 8 | 9 | 10 | 11 | 12 |
| 13 | 14 | 15 | 16 | 17 | 18 | 19 |
| 20 | 21 | 22 | 23 | 24 | 25 | 26 |
| 27 | 28 | 29 | 30 | 31 |
- 포트폴리오
- Java
- docker
- 디자인 패턴
- LV0
- 데이터 베이스
- S3
- Til
- 일정관리 프로젝트
- Join
- 프로그래머스
- LV01
- spring boot
- 연습문제
- CI/CD
- LV02
- 알고리즘
- Redis
- LV1
- LV.02
- GIT
- JPA
- SQL
- Lv.0
- 코테
- mysql
- CoffiesVol.02
- 이것이 자바다
- 일정관리프로젝트
- LV03
- Today
- Total
목록CI/CD (2)
코드 저장소.
프로젝트 배포3- CI부분에 캐싱 적용
목차1.도입 배경2.문제 분석3.캐시 적용4.느낀점 1.도입 배경CI/CD 파이프라인을 GitHub Actions로 구성한 이후, 커밋이나 PR마다 평균 2~3분의 빌드 시간이 소요되는 문제가 있었습니다.현재 프로젝트는 멀티모듈 Gradle 기반으로 구성되어 있으며, 외부 의존성도 많아 빌드 성능의 손실이 반복되고 있었습니다.단순한 변경 사항이나 테스트 커밋임에도 매번 전체 빌드를 새로 수행해야 했고, 이로 인해 개발 흐름이 끊기거나 PR 리뷰 속도가 느려지는 병목이 발생했습니다.운영 환경 배포를 자동화하기 위해 CI를 구성했지만, 오히려 개발 속도를 방해하는 상황이 생긴 것입니다.2.문제 분석GitHub Actions는 매 빌드마다 새로운 VM 환경에서 실행되기 때문에, 기존에 다운로드된 의존성 파일(..
프로젝트 배포2 - GithubAction 을 활용한 CI/CD구축하기.
목차1. 도입 / 배경2.MobaXterm을 활용한 배포 자동화 & 운영3.후기 1. 도입 / 배경지난글에서는 배포를 할 기본적인 인프라를 세팅을 했고 이번에는 GithubAction을 활용해서 CI/CD를 구축을 하기로 했습니다. CI/CD를 적용을 하게 된 이유는 아래와 같습니다.수동으로 서버를 올리면서 배포를 하면 작업을 하는데 있어서 시간소모가 크다.작업을 하면서 운영을 하기 위해서는 빌드,테스트,배포를 자동화하는 것이 필요.위와 같은 이유로 GithubAction을 사용해서 CI/CD를 구축을 하고자 합니다. 그래서 이번글의 목표는 아래와 같습니다.main 브랜치에 코드가 머지되면 자동으로 빌드/테스트/배포가 이루어지게 만드는 것운영 서버에서는 실제 서비스가 무중단으로 배포/재시작되는 구조로 만..