컨테이너

 이것저것 시도해 봤는데, 아무래도 한 세팅에 한 앱을 사용한다는 느낌으로

여러가지를 하나의 시스템에 통합하려는 시도는 애초에 포기하고 하나의 세팅으로 하나의 작업이 가능하다면 깔끔하게 그것만 분리해서 하는게 좋다.

그게 컨테이너의 목적이고.

하다보면 어느정도 경험이 쌓이고 다목적으로 만들 수 있는 시스템을 쌓을 수 없진 않겠지만, 하나의 작업을 할 수 있으면, 굳이 그거에 대해 업그레이드를 시도하다가 망가지는 거 보느니 한단계에 하나씩 컨테이너 하나에 작업 한단계로 구성하는게 여러모로 이익인 듯 싶다.

Comments

Post a Comment

Popular posts from this blog

기테스트 GiTest

테스트 별 코드 커버리지 깃 체인지 트래킹 이 두가지를 섞으면 체인지에 해당하는 테스트를 추려낼 수 있고, 그것만 돌리면 커밋당 최소 테스트를 돌릴 수 있다. 만약 이 형태를 로컬에서 돌릴 수 있으면 정말 최강의 스트레스 없는 TDD가 가능 할 것 같은데, 일단 이것저것 제한은 있다. 일차적으로는 이걸 서버쪽, 젠킨스쪽에서 돌리는 건 충분히 가능한게, 젠킨스는 일단 완전한 브랜치 커밋 기반 빌드가 보장되고, 기존 빌드에 대한 기록 저장도 로컬보다 유용하기 때문. 일단 저런 형태의 젠킨스 익스텐션 툴을 만들고, 그 다음 단계가 이걸 로컬로 끌어내리기를 하는게 좋을 듯 1. 현 커밋의 모든 테스트들을 뽑아내고 2 그 개별적인 테스트들을 각각 돌려서 개별 코드 커버리지를 뽑아내고 3 그걸 코드 라인별 어떤 테스트 커버가 있는지 자료를 만들고 4깃 체인지 로그에따라 관련된 테스트가 어떤게 있는지 찾아내는 것 5중간에 어떤 테스트가 추가되었는지 알아낼 수 있나? 동작순서 1 로컬개발 유닛 테스트 2 커밋과 푸쉬 3 젠킨스 빌드 및 라인별 테스트 결과에 대한 커밋 4 로컬 풀 (젠킨스 테스트 결과를 가지고 옴) 5 로컬 유닛테스트는 젠킨스의 테스트 결과를 기반 diff test 스케일러블 테스팅 디프 테스팅 오토 스윗 테스팅 테스트 스윗 옵티마이제이션 프리사이즈 스윗 ㅋㅋㅋ 프리사이즈 슈트 ㅋㅋㅋㅋ 투두 1 젠킨스 설치 2 젠킨스 빌드 설정 3 젠캔스 유닛테스트 설정 4 젠킨스 테스트 리스트를 가져오기 5 테스트 리스트에 따른 개별적인 테스트 실행 6 테스트 결과 가져오기 7 테스트 결과들을 머지/ 라인별 테스트 목록 작성 여기가 가장 힘든 부분. 라인별 테스트 목록을 어떤 형태로 만드는게 좋으려나  자료구조? 8 생성된 테스트 결과를 커밋하기 파일 구조를 어떻게 가져갈 지에 대해 고민해 봐야 함 루트 디렉토리에서 분기된 숨은 폴더 각 디렉토리+파일별 매핑을 따로 해야 하려나 9 diff test 현제 체인지 로그와 저장된 라인별 테스트 커버에 따라 테스트
Read more