Github을 사용하다 보면 Label 관리의 필요성을 느낄 때가 있습니다. 특히 팀으로 일하는 경우 동일한 규칙에 맞춰서 Label을 정해서 사용할텐데, 매번 새로운 저장소를 만들 때 마다 세팅을 해줘야 합니다.
그리고 Issue과 PR(Pull Request)의 경우도 마찬가지입니다. 특히 공개 된 저장소의 경우, 정해진 형식에 맞게 Issue와 PR을 올리는 것이 아니기 때문에 정리가 잘 안되는 경우가 많습니다.
그래서 이런 문제를 한번에 해결하고 싶어서, Label 세팅과 Issue, PR Template 이 담긴 저장소를 만들어서 Github 저장소 자체를 템플릿으로 사용할 수 있도록 하였습니다.
import { AuthResDto } from ‘../../src/auth/dto/response.dto’;
import { AuthService } from ‘../../src/auth/auth.service’;
import { AuthResDto } from ‘@auth/dto/response.dto’;
import { AuthService } from ‘@auth/accounts.service’;
./
├── package.json
├── src …
- 위에서도 언급했지만, app.yaml 파일에 env_variables 항목이 이미 있는 경우에는 정상적으로 동작하지 않습니다.
- 이미 존재하는 환경변수도 함께 사용할 수 있는 방식으로 보완하면 더 좋을 것 같습니다.
Bitbucket Pipelines로 Google App Engine에 자동 배포 시 안전하게 환경변수를 추가하는 방법을 소개합니다.
app.yaml
)에 환경 변수를 추가하는 방법은 env_varibles
항목에 key:value
형태로 평문 그대로 저장하는 방식입니다.app.yaml
파일에 API Key, Auth Token 등의 노출되면 안되는 정보들이 그대로 노출됩니다.app.yaml
파 …git clone https://github.com/<GITHUB_ID>/project-name.git
cd project-name
git submodule add -b master https://github.com/<GITHUB_ID>/project-name-client.git client
git submodule add -b master https://github.com/<GITHUB_ID>/project-name-server.git server
client, server
폴더와 .gitmodules
파일이 생성 됨기존 서비스 배포 시 프로세스의 불편함 점을 파악하고 개선하기 위해 도입한 과정을 총 3편에 걸쳐서 소개하려고 한다.
기존 서비스 배포 시 프로세스의 불편함 점을 파악하고 개선하기 위해 도입한 과정을 총 3편에 걸쳐서 소개하려고 한다.
기존 서비스 배포 시 프로세스의 불편함 점을 파악하고 개선하기 위해 도입한 과정을 총 3편에 걸쳐서 소개하려고 한다.
Docker 기반의 서비스를 AWS ECS에 배포할 수 있는 CI/CD 툴을 찾는 것을 목표로 한다.
필수 사항은 다음과 같다.
CI/CD는 애플리케이션 개발 단계를 자동화하여 애플리케이션을 보다 짧은 주기로 고객에게 제공하는 방법이다.