pepe

집에서 서비스를 오픈 해보자 (1) | 개요집에서 서비스를 오픈 해보자 (2) | 서버 세팅하기집에서 서비스를 오픈 해보자 (3) | dns 연결하기집에서 서비스를 오픈 해보자 (4) | CI/CD 연동하기집에서 서비스를 오픈 해보자 (5) | upptime 모니터링, status 페이지 추가하기   1. 소개Upptime은 Github(Github Actions)기반의 되어있는 uptime 모니터링, status 페이지를 제공하는 오픈소스입니다.3가지의 기능을 제공하고 있습니다. 1. Github Actions를 기반으로 workflows를 통해 웹 사이트를 호출합니다. x분(최소 5분)마다 실행합니다.2. 지정된 endpoint가 죽으면 Upptime은 Github repository에서 자동으로 새..

집에서 서비스를 오픈 해보자 (1) | 개요집에서 서비스를 오픈 해보자 (2) | 서버 세팅하기집에서 서비스를 오픈 해보자 (3) | dns 연결하기집에서 서비스를 오픈 해보자 (4) | CI/CD 연동하기집에서 서비스를 오픈 해보자 (5) | upptime 모니터링, status 페이지 추가하기  이전 포스팅에서는서비스를 오픈하여User가 서비스에 접근하는 부분까지 구현을 완료했습니다. 이번 포스팅에서는개발자가 Github에 코드를 push한 뒤Github Actions을 활용하여 CI/CD를 진행하도록 하겠습니다.   이 사진에서 developer가 GitHub에 코드를 push 했을 때 일어나는 일들을 구현할겁니다.코드를 push 하면 Raspberry Pi 안에 설치되어있는 Github Actio..

집에서 서비스를 오픈 해보자 (1) | 개요집에서 서비스를 오픈 해보자 (2) | 서버 세팅하기집에서 서비스를 오픈 해보자 (3) | dns 연결하기집에서 서비스를 오픈 해보자 (4) | CI/CD 연동하기집에서 서비스를 오픈 해보자 (5) | upptime 모니터링, status 페이지 추가하기    Web : https://klassic-quote.vercel.app/API : https://klassic-quote-api.mooo.com/v1/random-quote취미로 만들었던 서비스에서활용한 방법을 작성하였습니다.  집에서 서비스를 오픈하는 이유클라우드 비용을 사용하고 싶지 않았습니다. 사용자가 거의 없어서..그리고 집에 남는 컴퓨터가 있었습니다. 😁  집에서 서비스를 오픈하기 위한 준비물1...

이전 포스팅에서는 기본 페이지를 만들었습니다. 이번 포스팅에서는 원하는 내용을 수정 후 push 하여 내용이 변경되는지 확인해보겠습니다. 코드를 수정할 수 있도록 github repository에서 코드를 clone 합니다. git clone https://github.com/GHGHGHKO/slate.git Cloning into 'slate'... remote: Enumerating objects: 83, done. remote: Counting objects: 100% (83/83), done. remote: Compressing objects: 100% (75/75), done. Receiving objects: 98% (82/83)used 67 (delta 4), pack-reused 0 Rec..

slate는 markdown 수정만으로 API 문서를 만들 수 있는 오픈소스입니다. https://awesomeopensource.com/projects/api-documentation 여기서 가장 별이 높은 오픈소스를 참고했습니다. 이 오픈소스에서는 Using Slate Natively Using Slate in Vagrant Using Slate in Docker How to Edit Slate Markdown files Publishing with Slate — Either to Github Pages, or your own server. Github Pages Custom Domain Names with Slate 위와 같은 배포 방식을 사용할 수 있게 되어있습니다. 이 블로그에서는 Github ..

나 혼자 개발하는 건이면 상관 없을 수 있겠지만 모두가 한 repository에서 작업을 한다면 남이 봐도 이해하기 쉬운 커밋 메시지를 적어야 한다. 커밋 메시지를 잘 써야하는 대표적인 이유는 1. 더 좋은 커밋 로그 가독성 2. 더 나은 협업과 리뷰 프로세스 3. 더 쉬운 코드 유지보수 커밋 메시지는 주로 영어를 활용한다. 하지만 한국인끼리 협업을 한다면 굳이 영어를 쓸 필요가 있을까 싶다. 커밋 메시지는 아래와 같은 구조가 되어야 한다. [적용 범위(선택 사항)]: [본문(선택 사항)] [꼬리말(선택 사항)] 커밋에는 라이브러리를 사용하는 사람들에게 의도를 전달하기 위해 다음과 같은 구조적 요소가 포함된다. 1. fix: 코드 베이스에서 버그를 패치하는 fix 타입의 커밋(유의적 버전에서의 PATCH..

배포가 정기적으로 이루어진 팀, 프로젝트를 지원한다. 평소에 GitHub를 사용할 때 어떻게 흘러가는지에 대해 알 수 있다. 1. Create a branch master : 제품으로 출시될 수 있는 브랜치 develop : 다음 출시 버전을 개발하는 브랜치 feature : 기능을 개발하는 브랜치 release : 이번 출시 버전을 준비하는 브랜치 hotfix : 출시 버전에서 발생한 버그를 수정 하는 브랜치 위와 같은 브런치들이 있다. 꼭 지켜야 하는 것은 아니지만 협업을 한다면 따르는 것이 좋을 것 같다. 프로젝트를 진행하다보면 요구사항들을 받을텐데 가능한 요구사항이 있고 불가능한 요구사항이 있을 것이다. 프로젝트에서 브랜치를 새로 생성하면 새 메모장 처럼 여러 코드를 테스트 할 수 있는 환경이 만..