DevOps

API 명세서를 제공하지 않는 곳이 너무 많다.. 혼자 작업을 하더라도, API 테스트를 위해 Postman을 사용한다. 협력 작업시엔 내 생각엔 필수적으로 사용되는데 내가 여태까지 외부와 협력 할 때 API 명세를 제대로 받아서 본 적이 없다. 일반적인 프론트 개발자라면 많이 당황하게 될 것이고 API 명세서를 요청하게 될 것이다. 대부분 그럴 때 마다 돌아오는 답변이 시간도 없는데 그걸 언제 만들고 있어요.. 코드 보면서 하세요. 개인이 서버 테스트 할 때도 Postman 같은 툴로 테스트 하면서 진행하지 않나..? 싶지만 어쩔 수 없이 코드 보면서 분석하거나, 코드를 볼 수 없는 환경일 때는 진짜 추측해서 작업하는 경우도 잦았다. 물론 나중에 몰아서 API 명세서를 작업하려면 엄청난 시간이 들어가는..

테스트에 대하여 알아보다 생긴 궁금증.. 각종 테스트 기법, 테스트 종류들에 대해 알아보고 예제들을 보다가 계속 가시지 않는 궁금증이 하나 생겼다. "그런데 이거, 효율적이긴 한거야? 보다보니까 굉장히 이상한데?" 비 효율적이라고 생각되는 부분이 한두가지가 아니었다. 코드 작성자가 테스트 케이스를 만들면, 아무리 범용적으로 생각하더라도 본인이 작성자 이기 때문에 통과 용도로 밖에 테스트 케이스를 짜지 못할 확률이 높다. 무조건 테스트 케이스를 먼저 만들고 개발에 들어간다면, 너무 비효율적이다. 테스트 케이스가 많아질수록 개발에 방해가 될 요소가 너무 많다. (인력은 한정되어 있고, 기간도 마찬가지. 테스트 케이스에 대한 cost가 점점 늘어만 가는데 이부분을 해결하느라 실제 개발에 소비되는 cost가 줄..

DevOps, TEST 데브옵스(DevOps)의 모델을 보면 계획 부터 모니터링에 이르는 사이클이 있다. DevOps가 중요한 이유는 현재에 이르어서는 당연시 여겨지고 있기는 한데.. 궁극적으로는 더 빠르고 안전하게(오류없이) 소프트웨어를 제공함이 목적이다. 이 중에서도 TEST에 관한 부분에 대한 약간.. 개인적인 의견이 들어간 고찰(?)을 해보자고 한다. 테스트, 테스트 피라미드 테스트의 종류는 크게 세가지로 나뉘어 진다. 유닛 테스트(Unit Test), 통합 테스트 (Integration Test), E2E (End To End Test) 각각 짧게 알아보자면, - 유닛 테스트 (Unit Test) 유닛 테스트는 테스트 단계중 가장 작은 부분에 속하는데, 보통 작성한 함수가 정상적으로 돌아가는지를..

1. Typescript용 jest 설치 먼저, typescript에서 사용할 수 있게끔 jest를 설치해 준다. npm install ts-jest @types/jest --save-dev production 빌드시에는 jest가 필요 없으므로, --save-dev를 넣어서 설치해 주도록 하자. 2. babel 종속성 설치 https://jestjs.io/docs/getting-started#using-typescript Getting Started · Jest Install Jest using your favorite package manager: jestjs.io jest 페이지를 보면, Jest는 Babel을 통해 TypeScript를 지원한다고 나와 있다. 이에 필요한 모듈들은 다음과 같다. 1..

서론 지난번에는 Ansible과 gitAction을 통해 EC2에 자동 배포하는 인프라를 구축했었다. [gitAction] Ansible + gitAction을 이용한 EC2 자동배포 서론 이전에 Ansible playbook을 실행하면 각 서버에 배포 할 수 있게끔 처리를 해 두었다. 이제, git에 push가 실행되었을 때 해당 playbook을 실행할 수 있게 처리해 두면 진짜 자동배포가 완료된다! 변 jjong-factory.tistory.com 문제는, 마지막에도 언급 했듯이 잠시 테스트 용으로 만든거라 SSH 인증쪽을 전부 뚫어 놨다는 것.. 세상에는 나쁜 사람들이 많기 때문에 구멍난 곳을 서둘러 막아줘야 한다..! 그러기 위해서 먼저, 보안그룹을 설정할 수 있는 IAM 계정을 하나 만들어야 ..

서론 이전에 Ansible playbook을 실행하면 각 서버에 배포 할 수 있게끔 처리를 해 두었다. 이제, git에 push가 실행되었을 때 해당 playbook을 실행할 수 있게 처리해 두면 진짜 자동배포가 완료된다! 변수값 세팅 git Action에서 EC2 서버에 접근 할 수 있어야 하기 때문에, repo->Setting->Secrets and variables에 SSH_KEY값, HOST값, USER 값을 추가해 준다. deploy Action 작성 repo->gitActions->New workflow를 눌러 준 뒤, set up a workflow yourself를 눌러준다. name: deploy on: workflow_dispatch: push: branches: - [master-br..

서론 저번에 Ansible role을 일단 만들어 두었는데, 이를 이용하여 github을 여러 서버에 배포하는 playbook을 만들어 보자. 만든 role의 tree 구조는 다음과 같다. . ├── README.md ├── defaults │ └── main.yml ├── files ├── handlers │ └── main.yml ├── meta │ └── main.yml ├── tasks │ └── main.yml ├── templates ├── tests │ ├── inventory │ └── test.yml └── vars └── main.yml 변수 세팅 정적 변수는 defaults의 main.yml에 작성한다. --- # defaults file for arkinfo-deploy server..

Ansible role? Ansible role은 개발로 치면 일종의 FrameWork이라고도 볼 수 있겠다. 관리해야 할 서버가 많아지고, 해야 할 작업들이 많이지게 되면 playbook들도 많아 지게 될거고, 유지보수가 쉬우려고 사용한 Ansible을 유지보수 하느라 시간낭비를 할 수 도 있게 되는 상황이 올텐데 디렉토리 구조를 지정해 줌으로 써 이러한 상황들을 방지하는 역할이다. https://docs.ansible.com/ansible/latest/playbook_guide/playbooks_reuse_roles.html Roles — Ansible Documentation The classic (original) way to use roles is with the roles option for ..

서론 개발을 시작 할 때 쯤에는 DevOps라는 개념이 없었다. 요즘에는 협업, 어플리케이션의 안정성, 커뮤니케이션 코스트 감소, 빠른 개발 등 다양한 이유로 DevOps형태의 문화가 넓게 정착되었다. 그러면서 엔지니어들은 의외로 알아야 할 범주들이 또 넓어졌는데.. (업무 효율성이 올라가긴 하지만 공부해야 할 범위가 넓어진 것도 맞다) 개발과 커뮤니케이션 툴 이외에 추가적으로 알아야 할 개념들은 CI/CD , IaC , Monitoring , Test 등이 될 것 같다. 이중 IaC에 해당하는 Ansible과 CI/CD 쪽에 해당하는 Jenkins를 이용하여 EC2 자동배포 툴을 만들어 보려고 한다. Ansible쪽을 살펴보면서 여러 서버를 손쉽게 구축할 수 있도록 도와주기도 하고, 배포, 유지관리에도..