[WIP] Update requirements, migration dir

[dohvis]

No description provided.

[Kcrong]

@NeroGit migrations 폴더도 scrapy 파일임??

[dohvis]

?ㄴㄴ Alembic

[dohvis]

우리 원래 마이그레이션파일 관리 어떻게 했더라

[Kcrong]

마이그레이션 파일도 관리함?? 그냥 models.py 만 관리하면 되지 않음?

[dohvis]

관리해야지ㅇㅇ 실서비스하다 데이터 쌓였는데 모델 변경하면 터지잖음. 초기 개발 할때엔 안해도 되긴하는데 우린 크롤링하면서 데이터가 쌓이니까 관리 해야될거같응데

[Kcrong]

그럼 mysql 자체를 도커로 빼두고, models.py 수정 될 때마다 커밋 아이디로 태깅해서 도커 이미지 만들면 안되나?

[Kcrong]

예를 들어서
8hdk182
[ENH] Add personal info column at User table

이런 커밋이 있으면 dockerhub에서 저 내용이 담긴 mysql 이미지가 만들어지는거지
docker pull mysql:8hdk182
이런 식으로

[dohvis]

ㅇㅇ안됨 왜냐면 그 마이그레이션 하는 과정에서 테이블이름을 바꾸거나 하는게 마이그레이션파일의 역할인데 models.py 만 관리하면 실제 변경한게 디비에 저장이 안되니까

[Kcrong]

ㅇㅇ 그니까 실제 변경된 디비 자체를 도커 이미지로 관리하자는거지 그럼 롤백도 쉬울거 같은디?

[dohvis]

그리고 인프라의 변경이 아니라 어플리케이션단의 변경을 도커로 관리하는건 좀 이상한거같은데

[dohvis]

그러면 모델을 바꿀때마다 디비를 손으로 수정해야되는데 그러는 과정에서 어차피 마이그레이션파일은 만들어질수밖에없음

[Kcrong]

이미지도 어떻게 보면 어플리케이션의 VC인데?

[+] models.py가 변경 되면 circle ci에서 자동으로 이미지 만들고 dockerhub로 배포하게 가능함

[dohvis]

흠 굳이 도커없이도 할수있는걸 도커를 써야되나?.. 뭔가 git 안쓰고 버전관리 도커로 다하는느낌이야

[Kcrong]

마이그레이션 파일을 롤백할때는 어떻게 할건데?? 딱히 강한 이견은 없는데 서비스할 때 좀 더 편할 것 같아서 그렇지.

[dohvis]

Alembic에서 마이그레이션 파일 읽어서 그 버전으로 돌리면 되지

[Kcrong]

데이터는?

[dohvis]

데이터?

[Kcrong]

alembic migrations 파일에 insert 도 들어감?

[dohvis]

무슨말이야 그겡

[Kcrong]

우리가 서비스를 돌려서 디비에 데이터가 들어간 상황이라고 하고.
만약에 디비 구조를 rollback 하려고 하면 네가 말한
지난 버전 alembic의 migration 파일 읽는 방법으로도 우리 데이터를 보존할 수 있음??

[dohvis]

https://github.com/nerogit/kakaotalk-visualization/blob/master/src/alembic/versions/d4a273582ce8_initial_commit.py

ㅇㅇ플라스크에선 안해봤는데 장고에서는 마이그레이션 실행할때 구조달라졌다고 데이터 마이그레이션하라고 쉘열어줘 아마 알렘빅에선 그 코드를 마이그레이션파일에 넣어야할듯?

[Kcrong]

하긴 도커로 버전관리해도 버전간에 차이나는 데이터는 보장이 안되네
차라리 수동으로 마이그레이션하는게 낫겠다
migrations 버전관리하는걸로 하자

[dohvis]

오켕 근데 첫 릴리즈 전까지는 관리 안하는게 낫더라ㅋㅋ

[Kcrong]

헐 그래? 난 사내 모듈 만들면서 정 반대라고 생각했는데 ㅋㅋㅋ 여튼 오키