static : 정적, 실행 전에 결정
dynamic : 동적, 실행 중에 결정
파이참 오른쪽 db 에서 연결 시키기
안에서 sql문 실행 시켜서 확인
poetry add pymysql cryptography
poetry add -D **types-PyMySQL**
pymysql.install_as_MySQLdb()
DATABASES = {
"default": {
"ENGINE": "django.db.backends.mysql",
"NAME": "oz_django",
"USER": "root",
"PASSWORD": "1234",
"HOST": "localhost",
"PORT": "3306",
}
}
poetry add django-stubs : 장고의 타입힌팅 지원 패키지가 설치
dev dependency <--> dependency (poetry add -D 패키지, poetry add 패키지)
프로젝트 생성
ignore 생성, .gitignore
.idea/
venv/
__pycache__/
`poetry add ipython
- codeformatter: 여러 개발자의 코드 스타일을 통일시켜주는 패키지
- ex) ' ' -> " " , 공백... 맞춰진것 commit 목록에서 확인 가능
- poetry add -D black
poetry run black .
poetry.toml 추가
# 자동으로 넘겨지는것 방지 기존이 80
[tool.black]
line-length = 120
# 파이참 수정
# preference -> editor -> code style -> hard wrap at : 설정한 블랙 값으로 수정
poetry run isort .
- 알파벳 순서를 맞추는 정도의 동작.
[tool.isort]
profile = "black"
- 코드를 읽고 잠재적인 에러를 찾는다
poetry run mypy .
[tool.mypy]
plugins = ["mypy_django_plugin.main"]
python_version = "3.13"
strict = true # mypy 진가 타입을 엄격히 써야함
[[tool.mypy.overrides]] # 특정한 모듈에 한해서 덮어쓰겠다.
module = "*.migrations.*"
ignore_errors = true # 위의 폴더에 관해서는 mypy를 무시하겠다. 어차피 장고에서 만들어주니
[[tool.mypy.overrides]]
module = "manage"
ignore_errors = true # 위의 폴더에 관해서는 mypy를 무시하겠다. 어차피 장고에서 만들어주니
[tool.django-stubs]
django_settings_module = "폴더명.settings" # settings의 경로 명시
reveal_type(어떤 타입이 들어가 있는지 확인할 타입명)
: from typing import reveal_type
- Continuous integration(CI)
- github에 push 할 때마다 테스트가 자동으로 실행되도록 만들기
- ci.yml 안에있는 내용을 github에서 docker처럼 새로 만들고 테스트 해본후 없앤다.
- 독립된 환경에서 독립적인 자기만의 데이터를 가지고 실행
Continuous IntegrationCI 가 필요한 이유 : 수십 명이 하나의 코드베이스에서 작업을 할 때
다음과 같은 과정을 반복하게 됩니다.
- 테스트가 끝난 코드(master)에서 새로운 branch 를 생성합니다.
- 새로운 branch 에서 작업합니다. (기능 추가, 최적화 등등)
- 로컬에서 테스트 합니다.
- PR 을 올립니다. 코드리뷰, 테스트
- 개발서버에 배포 합니다. (staging), 개발 서버에서 기계를 통해 기존의 기능까지 전부 잘되나 검증
- develop 서버에서 테스트 합니다.
- master 에 merge, 배포합니다.
이렇게 작업할 때 마다 반복적인 작업이 있습니다. PR 을 올리기 전에 테스트를 다 통과해야 한다는 점, merge 할 때 마다 테스트 해야 하는 점 등이죠.
이를 자동화 함으로써
human error 를 줄입니다.
반복적인 작업에 들어가는 시간을 아낌으로써 더 효율적으로 일할 수 있습니다.
.github/workflows/ci.yml
폴더 및 파일 생성name: Django CI
# 트리거 언제 실행한건 지
on:
push: # 푸쉬 할때마다
# workflow_dispatch: # 그 버튼을 누르면 실행
jobs:
ci:
runs-on: ubuntu-22.04 # github action 이 제공하는 ubuntu는 mysql 이 기본적으로 설치되어 있음
env:
# 환경 변수
DB_HOST: 127.0.0.1
DB_PORT: 3306
DB_USER: root
DB_PASSWORD: 1234 # 깃허브에 넣는거라 비밀번호 의미없음
DB_DATABASE: oz_django
steps: # 단계
- name: Check out the codes
uses: actions/checkout@v2
- name: Setup python environment
id: setup-python
uses: actions/setup-python@v2
with:
python-version: '3.13'
- name: Set timezone to KST
run: |
sudo rm /etc/localtime
sudo ln -s /usr/share/zoneinfo/Asia/Seoul /etc/localtime
# Start Mysql
# https://ovirium.com/blog/how-to-make-mysql-work-in-your-github-actions/
- name: Start Mysql
# 이미 설치된 mysql을 단순히 킴
run: |
sudo systemctl start mysql
mysql -e "use mysql; FLUSH PRIVILEGES; ALTER USER '${{ env.DB_USER }}'@'localhost' IDENTIFIED BY '${{ env.DB_PASSWORD }}';" -uroot -proot
mysql -e 'CREATE DATABASE ${{ env.DB_DATABASE }};' -u${{ env.DB_USER }} -p${{ env.DB_PASSWORD }}
- name: Install Poetry
run: |
curl -sSL curl -sSL https://install.python-poetry.org | POETRY_VERSION=2.0.1 python3 -
echo "${HOME}/.local/bin" >> $GITHUB_PATH
- name: Install dependencies
run: |
poetry install --no-root
- name: Run black
# check 만 하고 실제론 바꾸지 않는다 우리 프로젝트에서 바꿔야 하니까
run: |
poetry run black . --check
- name: Run isort
# 마찬가지
run: |
poetry run isort . --check --diff
- name: Run Mypy
run: |
poetry run mypy .
# - name: Test python project
# run: |
# poetry run python manage.py test
on: push
→ 액션이 언제 실행되는지를 정의합니다. on: push
라면, push 할 때마다 실행합니다. https://docs.github.com/en/actions/learn-github-actions/workflow-syntax-for-github-actions#onjobs
→ 하나의 workflow 는 여러개의 job 으로 구성됩니다. 여기서는 ci 라는 이름(id)의 job 하나만 정의하여서 사용하였습니다. https://docs.github.com/en/actions/learn-github-actions/workflow-syntax-for-github-actions#jobsruns-on
→ job 이 실행되는 machine 을 의미합니다. github 가 제공하는 ubuntu-latest (현재 버전 20) 을 사용합니다. https://docs.github.com/en/actions/learn-github-actions/workflow-syntax-for-github-actions#jobsjob_idruns-onsteps
→ 하나의 job 은 여러개의 step 으로 구성됩니다. step 은 명령을 실행하거나 다른 action 을 실행합니다.uses
→ 실행할 action 을 가리킵니다.with
→ action 에 전달할 parameter 변수입니다.run
→ 실행할 명령어입니다.run: |
→ yaml 문법입니다. |
(파이프라인)을 사용해 value 가 여러 줄(multiline) 이라는 것을 의미합니다.TL; DR:
push 될 때 마다 → 우분투에서 → 파이썬을 설치하고 → poetry, django, 등등등 종속성 설치하고 → test 를 실행한다.
git remote add origin https://github.com/deokbaae/oz_django.git
pycharm 에서 shift 2번 연타 후 push
github login
poetry add coverage
패키지 설치를 한다.chmod +x ./test.xh
를 통해 관리자 권한으로 허용해준다./test.sh
set -eo pipefail
COLOR_GREEN=`tput setaf 2;`
COLOR_NC=`tput sgr0;` # No Color
echo "Starting black"
poetry run black .
echo "OK"
echo "Starting isort"
poetry run isort .
echo "OK"
echo "Starting mypy"
poetry run mypy .
echo "OK"
echo "Starting test with coverage"
poetry run coverage run manage.py test
poetry run coverage report -m
echo "${COLOR_GREEN}All tests passed successfully!${COLOR_NC}"
Agile(애자일) 은 소프트웨어 개발 및 프로젝트 관리에서 유연하고, 빠르고, 협업 중심으로 작업하는 방법론입니다.
기본 철학: 작은 단위로 빠르게 개발하고, 지속적으로 피드백을 반영하여 개선하는 방식
애자일의 기본 원칙은 "애자일 선언(Agile Manifesto)"에서 정의되었습니다.
즉, 빠른 피드백, 반복적인 개선, 고객과의 협업이 애자일의 핵심입니다. 🚀
방법론 | 특징 |
---|---|
Scrum (스크럼) | 짧은 개발 주기(스프린트 ), 역할 분담 (Product Owner, Scrum Master, Dev Team) |
Kanban (칸반) | To Do - In Progress - Done 형태의 시각적 관리 시스템 |
XP (익스트림 프로그래밍) | TDD(테스트 주도 개발), 페어 프로그래밍, 지속적 배포 |
Lean (린 개발) | 낭비 최소화, 최적의 효율성 추구 |
📌 이 과정이 반복되면서 지속적인 개선이 이루어짐!
비교 항목 | 애자일 (Agile) | 워터폴 (Waterfall) |
---|---|---|
개발 방식 | 반복적(Iterative) | 순차적(Sequential) |
요구사항 | 계속 변경 가능 | 초기에 확정 |
피드백 반영 | 빠르게 반영 가능 | 다음 개발 단계까지 반영 불가 |
고객 참여 | 지속적인 협업 | 초기 및 최종 단계에만 참여 |
문서화 | 최소한의 문서 | 상세한 문서 작성 필요 |
🔥 애자일은 유연하게 변화에 대응 가능,
⚠️ 워터폴은 계획이 확실할 때 적합
✅ 빠른 피드백 반영 → 고객 요구사항을 신속하게 적용 가능
✅ 변화에 유연하게 대응 → 요구사항 변경 시 큰 문제 없이 진행 가능
✅ 지속적 개선 & 품질 향상 → 짧은 주기로 반복 개발하며 품질 향상
개념 | 설명 |
---|---|
애자일 (Agile) | 빠르고 유연한 개발 방법론 |
애자일 핵심 원칙 | 팀워크, 실행 가능 소프트웨어, 고객 협업, 유연성 |
애자일 방법론 | Scrum, Kanban, XP, Lean |
애자일 장점 | 빠른 피드백, 변화 대응, 지속적 개선 |
DTO(Data Transfer Object) 는 데이터를 전달하기 위한 객체로,
클라이언트와 서버 또는 애플리케이션 내부에서 데이터를 효율적으로 주고받기 위해 사용됩니다.
1. 데이터 전달을 위한 객체 (Request / Response)
• API 요청/응답 시 데이터를 정리하여 전달
2. 불필요한 데이터 노출 방지
• 민감한 정보를 숨기고 필요한 데이터만 포함 가능
3. 데이터 변환 (예: 모델 → DTO, DTO → JSON)
• ORM 모델을 API 응답 형식으로 변환할 때 사용
📌 쉽게 말하면?
➡️ “딕셔너리(dict)보다 구조화된 데이터 전송을 위해 사용하는 클래스!”