나름 개발자의 IT블로그

배포도 잘되고 페이지도 잘 보이는데 불편한게 하나 있다. 바로 도메인이다. 현재 기본으로 사용하는 도메인은 github에서 제공하는 도메인이라 살짝 길고 불편할 수 있다. 여기에 커스텀 도메인을 사용해보자. 커스텀 도메인 일단 package.json에서 사용할 도메인으로 변경하고 push한다. // package.json { "homepage": "https://page.riroan.com", // 생략 ... 그 후 도메인을 구매한 페이지에서 CNAME으로 사용할 도메인을 riroan.github.io를 가리키게 설정한다. 나의 도메인이 깃허브를 찾을 수 있도록 레코드도 추가해야 한다. 그리고 깃허브 Repository에서 Settings -> Pages 밑으로 가면 custom domain이 나온다...

프로젝트 수정 프로젝트를 수정하고 다시 배포하려면 어떻게 해야할까? // App.js function App() { return 안녕하세요 } export default App 굉장히 간단한 수정을 하고 배포 명령을 다시 실행해봤다. npm run deploy deploy명령을 실행하면 github actions가 자동으로 동작하며 배포를 수행한다. 완료되면 ctrl+shift+r을 눌러 강제 새로고침을 하고 수정한 내용을 확인할 수 있다. Github Actions 우리는 위에서 한 과정을 Github Actions를 통해 push하면 자동으로 배포하게 할 수 있다. # .github/workflows/deploy.yml name: Deploy on: [push] jobs: deploy: name: D..

나는 지금까지 프론트엔드 페이지를 서버에 올려서 nginx로 가리키는 형식으로 배포해왔다. 최근에 깃허브 액션을 공부하며 gh-pages라는 편리하고 서버 없이 배포할 수 있는 방법을 알게돼서 신세계를 경험했다. 잊어버리기 전에 기록해두자. 프로젝트 준비 나에게 가장 익숙한 리액트를 사용할 것이지만 어떤 프레임워크를 사용해도 상관 없다. npx create-react-app my-page code my-page 프로젝트 생성 후 깃허브 repository도 만들어서 올려놓자. gh-pages 패키지 설치 이제 배포하기 위한 npm 패키지를 설치해야 한다. npm install gh-pages --save-dev yarn add gh-pages --save-dev 둘중 사용하는 것으로 설치하자. 그 후 배..

들어가기 전에 지난시간 test를 실패하게 만들어서 정상적으로 작동하지 않을 것이다. 이를 성공하도록 만들자. # test.py def test1(): assert 1+1 == 2 def test2(): assert 1+2 == 3 브랜치와 폴더 지금까지 작성한 워크플로우는 아무데나 push만 하면 작동하도록 만들었다. 이번에는 브랜치별로 나눠보고, 폴더별로 나누는 옵션을 적용해보자. 일단 temp 브랜치를 위한 워크플로우를 만들건데 이 브랜치를 위한 워크플로우를 main 브랜치에 만든다. # ./github/workflows/temp.yml name: temp branch on: push: branches: - temp jobs: job: runs-on: ubuntu-latest steps: - nam..

테스트코드 우리는 개발을 하면서 이 코드가 올바르게 작동하는지 테스트코드를 작성하곤 한다. 심지어 TDD를 사용한다면 개발을 안한상태에서 테스트코드부터 작성한다. 이렇게 테스트코드를 작성하면 배포하기 전에 한번 돌려본 후 모든 테스트를 성공해야 배포를 할 수 있다. 그럼 테스트하는 workflow를 추가해보자. pip install -U pytest 우선 pytest로 테스트를 하기 위해 의존성을 설치한다. 그리고 테스트코드를 작성한다. # test.py (local) def test1(): assert 1+1 == 2 파일 이름은 pytest특성상 test가 포함되어야 하고 함수명도 마찬가지이다. 실행은 pytest test.py를 쓰면 된다. 일단 yml 파일을 작성하기 전에 테스트 작업은 꼭 ssh..

main.yml 우선 지난시간에 작성한 yml파일부터 살펴보자. name: auto pull github actions에서 보일 이름을 정하는 부분이다. 원하는대로 지으면 된다. on: [push] 언제 이 워크플로우를 작동할지 정하는 코드이다. 어느 브랜치든 어떤 폴더든 푸시만하면 작동하게 설정했다. 옵션으로 push, pull request, issue를 정할 수 있고 브랜치별, 폴더별로도 정할 수 있다. jobs: build: name: Build runs-on: ubuntu-latest 이제 push가 되면 무슨 행동을 할 지 정해야한다. build: 라고 쓰여진 부분도 별칭이니 바꿔도 된다. 일단 이름을 Build라고 정했다. (실제 빌드하는 작업은 아니다) 그리고 그 작업을 수행할 서버를 gi..

CI/CD은 빠르고 편리한 빌드/테스트/배포를 위한 과정을 의미한다. 이미 배포한 서비스를 업데이트하기 위해 git push를 하고 모든 테스트가 통과된다면 자동으로 배포가 되는 편리한 기능이다. 이를 위한 소프트웨어로 유명한 Jenkins, Bamboo등이 있다. 이러한 소프트웨어는 개인 서버에 설치가 되어 관리가 돼야 한다. 하지만 그 서버가 고장나거나 Jenkins가 다운된다면 난처한 상황이 생길것이다. 이를 위해 Github나 Gitlab에서 클라우드같이 컴퓨터를 대여해주는 식으로 CI/CD서비스를 제공해준다. 그 중 Github Action을 이용한 CI/CD를 알아볼 것이다. CI/CD가 없다면 1. 개발을 한다. 2. 테스트를 돌린다. 3. 테스트가 모두 통과된 것을 확인하고 원격 저장소에 ..