쵸코쿠키의 연습장

이 튜토리얼에서는 더 이상 사용하지 않는 docker 이미지의 로컬 환경을 정리하는 방법을 살펴 보겠습니다. Docker는 훌륭하지만 다운로드 한 이미지 및 컨테이너 중 일부는 컴퓨터에서 많은 공간을 차지할 수 있습니다. 이러한 이미지 중 일부는 더 이상 개발하지 않는 오래된 프로젝트에 대한 것일 수 있으므로 이미지를 로컬로 가질 필요가 없습니다. 어떤 이유로든 프로젝트가 도커로 돌아 가야하는 경우 로컬에서 찾을 수 없는 이미지를 쉽게 다운로드 할 수 있습니다. 도커 사용량 보기 명령어 사용하기 $ docker system df 이미지, 컨테이너 및 볼륨이 얼마나 많은 공간을 사용하고 있는지 확인할 수 있습니다. $ docker system df TYPE TOTAL ACTIVE SIZE RECLAIMAB..

Github 액션을 사용하여 마스터로의 병합에서 라벨 애플리케이션에서 PHPUnit 테스트를 실행하는 방법을 살펴 보았습니다. 테스트가 성공한 다음 단계는 도커 이미지를 빌드하고이를 저장소에 푸시하는 것입니다. 테스트가 성공적으로 완료되고 도커 이미지를 리포지토리에 푸시 한 후에 실행할 새 워크 플로 파일을 만들어야합니다. 먼저 워크 플로 폴더 .github/workflows/docker.yml에 새 파일을 만들고 해당 파일에 다음을 붙여 넣습니다. name: Docker on: push: branches: [ master ] jobs: build: runs-on: ubuntu-latest steps: - name: 'Checkout GitHub Action' uses: actions/checkout@v..

Docker를 사용하도록 개발 프로세스를 옮겼다면 기본 인프라에서 실행하는 것보다 성능 차이가 있음을 알 수 있습니다. 다음은 특히 MacOS를 사용하는 개발자에게 로컬 컴퓨터의 도커 속도를 높이는 데 사용할 수 있는 몇 가지 팁입니다. 볼륨 최적화 이것은 로컬 컴퓨터의 도커 성능에 가장 큰 영향을 미칩니다. 볼륨 캐싱을 향상시킬 수 있으면 응용 프로그램의 로딩 속도가 크게 향상됩니다. Docker 17.04부터 두 개의 새로운 옵션이 Docker 볼륨의 cached 및 delegated에 추가되었습니다. 경우에 따라 컨테이너의 파일과 로컬 컴퓨터의 파일간에 정확한 동기화가 필요합니다. 올바른 파일 시스템 캐시를 선택하면 개발 환경의 성능을 향상시키는 데 도움이됩니다. consistent : 완벽한 일관..

Docker는 컨테이너를 사용하여 환경을 마무리함으로써 가상 머신 구매와 같은 자체 환경에서 완전한 파일 시스템을 실행할 수있는 소프트웨어입니다. 여기에는 코드, 런타임, 시스템 도구 및 시스템 라이브러리를 실행하기 위해 이 모든 것이 포함되며, 이는 자체 서버를 실행하는 데 필요한 모든 것입니다. 모든 컨테이너가 다른 컨테이너와 동일한 커널을 공유하기 때문에 가상 머신의 아키텍처는 다릅니다. 그러나 다른 모든 종속성은 독립적으로 실행될 수 있습니다. 이것은 구성 파일을 사용하여 응용 프로그램이 올바르게 실행되도록 서버에 필요한 모든 종속성을 추가합니다. 예를 들어 응용 프로그램을 실행하려면 특정 버전의 PHP가 필요한 경우 도커 환경을 만들면 동일한 환경을 쉽게 공유 할 수 있습니다. 프로젝트의 모든 ..

최근 업무를 진행하면서 종종 DevOps에 대해 듣고는 하였습니다. 그 과정에서, 정확히 DevOps가 무엇인 지, 이해하지 못하고 있었고, Docker와 같은 하나의 신기술 정도로만 생각을 하였습니다. 하지만 이번 강좌를 통해서, 그 생각이 매우 틀렸다는 것을 알게 되었습니다. SW 개발해나가는 과정 역시 진화하고 있고, 떠오르는 개발 방법론이라는 것을 이해하게 되었습니다. 저도 모르게 평소에 실천했던 사례 중에 DevOps와 유사한 경험도 있다는 것을 알게 되었고, 또 잘못된 접근을 하고 있는 사례도 생각나게 되었습니다. 이 강좌는 오픈 소스를 통한 DevOps 환경을 이해할 수 있습니다. 또한, 가장 많이 활용되는 도구와 툴에 대해 공부할 수 있고, 그러한 툴을 활용해 개발,통합, 테스트, 배포, ..

End to End Test 엔드-투-엔드 테스트는 시스템이 외부 요구 사항을 충족시키고 전체 시스템을 끝까지 테스트하여 목표를 달성하는지 확인합니다. 다른 테스트와 달리 사용 중인 컴포넌트나 아키텍처와 관계없이 시스템이 전체적으로 비즈니스 목표를 충족하는지 확인하는 데 집중합니다. 이를 달성하기 위해 시스템은 블랙박스로 취급하여 GUI 및 서비스 API와 같은 공개 인터페이스를 통해 가능한 한 완벽하게 배포 된 시스템을 테스트합니다. 이런 종단 간 테스트를 통해 문제 영역에 대해 더 많이 알게 되면 서비스는 분할되거나 병합될 가능성이 있으며, 마이크로 서비스 아키텍처는 시간이 지남에 따라 발전할 수 있습니다. 하지만 테스트 범위가 훨씬 넓어 실패할 가능성이 매우 높습니다. UI 테스트 UI 테스트를 엔..

서비스 테스트 ‘서비스’라는 용어는 사람에 따라 의미가 모호할 수 있지만, 일반적으로 서비스 테스트라는 것은 UI 등 사용자 인터페이스를 우회해서 서비스들을 직접 테스트하는 것을 말합니다. 여러 서비스로 구성된 시스템 대상으로 단일 서비스만 테스트할 경우, 독립적으로 문제를 검증하기 위해 다른 서비스는 스텁으로 만들어서 테스트할 서비스의 범위를 제한하게 됩니다. 일부 작은 서비스 테스트는 빠르게 끝나겠지만, 실제 DB 또는 네트워크를 통해 테스트한다면 테스트 시간은 늘어날 것입니다. 단위 테스트보다 더 많은 범위를 다루므로 테스트 실패 시 문제의 원인을 찾기가 더 어려울 것입니다. 통합 테스트 서비스 테스트 중 하나인 통합 테스트는 화면의 박스 부분처럼 구성 요소 간의 네트워크 경로 및 상호 작용을 검증..

단위 테스트 트렌드 예전에는 UI 화면이나 장비 등의 필요한 기능을 조작하여 내용을 확인해서 테스트했으나, 현재는 작성한 프로그램을 테스트하기 위한 테스트용 프로그램을 작성후 실행시켜 확인합니다. 테스트용 프로그램을 만들기 보다는 UI 화면으로 테스트하는 것이 빠를 것 같지만, 테스트용 프로그램을 작성하게 되면 같은 내용의 테스트를 반복해서 자동으로 테스트할 수 있는 장점이 있습니다. JUnit 많이 사용 되는 JUnit은 단위 테스트 작성을 지원하는 xUnit 계열의 오픈소스 자바 프레임워크입니다. 여기서 xUnit은 단위 테스트 작성을 지원하는 여러 언어별 오픈소스 프레임워크를 말합니다. TDD 개념을 정립하고 애자일 방법론의 한 형태인 XP를 만든 켄트 벡과 GoF 패턴을 집대성한 에릭 감마에 의해..

단위 테스트 단위 테스트는 테스트 가능한 소프트웨어의 가장 작은 부분을 실행하여 예상대로 작동하는지 확인하는 것입니다. 즉, 시스템의 소스 코드 로직 등을 테스트로 점검하는 단계로 주로 소스 코드의 클래스나 메서드 단위의 기능이 정상적으로 동작하는지 검증합니다. 테스트 중인 단위가 작을수록 단위 테스트를 사용하여 동작을 표현하는 것이 쉬워지므로 단위의 분기 복잡성이 낮아집니다. 개발 단계에서 개발자 또는 개발팀 차원에서 직접 수행을 하여 자신이 코딩한 메서드나 클래스가 정상적으로 동작하는지를 테스트하는데, 주로 기능이 제대로 작동하는지를 점검합니다. 즉, 그 결과가 기대값과 일치하는지 확인하는 형태이며, 서비스 호출, 외부 파일/네트워크 연결 없이 서로 독립적으로 수행되어야 합니다. 단위 테스트는 버그를..

Digital Transforamation & Software Testing 오늘날 기업은 디지털 트랜스포메이션을 통해 초일류 기업으로 도약하려고 하고 있고, 소프트웨어는 그 중 필수적이고 중요한 부분이 되고 있습니다. 혁신의 속도를 빠르게 하려면 고품질의 소프트웨어를 보다 빨리 제공하고 제대로 동작하는지 확인할 수 있는 방법이 필요합니다. 그래서 소프트웨어 테스트가 중요한데, 개발된 소프트웨어가 요구사항대로 되었는지, 기능이 제대로 동작하는지, 안정적인지, 확장 가능한지 등 다양한 면에서 검증되어야 합니다. 테스트 자동화의 중요성 전통적으로 소프트웨어 테스트는 애플리케이션을 테스트 환경에 배포 후 사용자 인터페이스 또는 UI를 클릭해서 문제를 찾는 수동적인 방식으로 진행했습니다. 모든 변경 사항을 수동..

관심사의 분리 낮은 결합도, 높은 응집도를 가지게 하는 관심사의 분리 방법에 대해서 알아보겠습니다. 클래스 간 결합이 일어날 때 느슨하게 되어야 하는데, 그렇지 못할 경우 시간이 지남에 따라 왜 문제가 되는지 살펴보겠습니다. 웹 어플리케이션의 비즈니스 로직 계층에 멤버 정보를 처리하는 Service 클래스가 있다고 가정하겠습니다. 처음에는 멤버 정보 조회, 존재 여부 확인, 정보 변경을 처리하는 세 가지 기능으로 이루어진 Service 클래스입니다. 이 클래스를 서비스 발행 계층에서 front end 등 외부에 REST API로 노출하는 방식은 시간이 지나서 알림의 종류를 받고, 등록 및 해지하는 새 요구사항을 받게 되어 화면처럼 관련 메서드가 새로 추가하게 되었습니다. 서비스 발행 계층에서 추가된 메서..

클래스 추출 처음에 해당 클래스가 담당할 책임이 정확히 무엇인지 관련 기능을 포함하는 클래스를 생각해야 합니다. 이는 단일 책임 원칙을 준수하는 데 중요하고, 단일 책임 클래스는 안정적이고 변경에 좀 더 유연합니다. 물론 과도하게 리팩토링하는 것은 아닌지 항상 주의해야 합니다. 기존 코드를 복사해 쓰는 건 훨씬 빠르게 느껴지지만 이렇게 복사한 코드는 중복이기 때문에 곧 문제가 되고, 모든 소프트웨어의 가장 심각한 문제로 발전하게 됩니다. 상위 클래스로 추출 두 개 이상의 클래스들 중에 공통적인 소스가 있을 경우 공통적으로 사용하게 추출할 수 있습니다. MinorMember와 SeniorMember 클래스에서 공통적으로 멤버 ID로 DB 쿠폰을 조회 후 그 중 현재 기준으로 사용가능한 쿠폰을 설정 후 개별..

설명변수로 변환 설명변수로 변환하는 방법에 대해서 알아보겠습니다. if문 등 조건문의 복잡한 표현을 나누는 가장 쉬운 방법은 작게 분리한 설명 변수를 사용하는 방법이 있습니다. 제어 플래그 삭제 상태를 기록하고 처리 흐름을 제어하기 위한 boolean type 변수를 제어 플래그라고 합니다. 이 제어 플래그를 지나치게 사용하면 처리 흐름을 파악하기 어려워져서 전체를 파악하기 어렵습니다. 그럴 경우 break, continue, return 등을 사용해 조건문의 의미와 제어 흐름을 명확하게 합니다. 플래그명도 flag, state보다는 found, initialized, debug, error, done, aborted, interrupted 등의 이름이 더 좋습니다. 배열을 객체로 변환하는 방법에 대해서..

리팩토링 개념과 필요성 유명한 프로그래머 Kent Beck과 architect Martin Fowler는 소프트웨어 코드 안에서 나오는 여러 문제에 대해 Code Smell이라는 용어를 사용하였습니다. 즉, 코드가 시간이 지나면서 요구사항과 기능들이 추가되면서 추상화, 모듈화, 캡슐화가 되지 않고, 높은 결합성, 낮은 응집성, 낮은 가독성으로 이루어진 코드로 변하면서 점점 유지, 보수 및 확장이 어려운 어플리케이션이 되어가는 상태를 말합니다. 그런 코드를 대상으로 리팩토링이 필요한데, 여기서 코드 리팩토링이란 기존 코드를 재구성하여 외부동작을 변경하지 않고 내부구조를 변경하는 체계적 코딩 기술을 말합니다. 코드 리팩토링을 잘 수행하면 소스 코드의 로직을 단순화하고 불필요한 수준의 복잡성을 제거하게 됩니다..

소나큐브 사용 방법 우선 먼저 소나큐브 구동을 살펴보도록 하겠습니다. 소나큐브 사이트에서 배포 파일을 다운로드 후 설정 파일을 개발환경에 맞는 IP, 포트, 콘텍스트 등의 정보를 수정 후 소나 서비스를 실행합니다. 필요에 따라 이클립스 마켓 플레이스에서 제공하는 플러그인을 추가로 설치 가능합니다. 주요 플러그인으로는 파인드버그, 파인드 시큐리티 버그, PMD, 소나 HTML 등이 있습니다. 로그인 후 탑 메뉴를 통해 소나큐브의 기능을 사용할 수 있습니다. 프로젝트 메뉴는 소나큐브에서 관리하는 프로젝트 목록을 확인할 수 있습니다. 개별 프로젝트명을 클릭 후 나오는 오버뷰 화면은 분석 결과의 전체적인 내용을 요약해서 보여줍니다. 이슈 화면은 현재 프로젝트에서 활동 사항을 보여줍니다. 좌측의 필터 기능 사용 ..

SonaQube 특징 여러 분석 툴을 종합하여 여러 항목들을 한번에 검사한 후 웹페이지에서 분석 결과들을 손쉽게 확인 가능합니다. 또한 각종 플러그인을 이용하여 다양한 기능을 제공합니다. 실행하려면 JDK8 이상, 최소 2기가 이상의 램과 운영체제 실행을 위한 1기가의 여유 램, 분석을 위한 저장공간이 필요합니다. 클라우드 지향형 소나 클라우드, IDA 확장 플러그인 형태인 소나린트도 있어 다양한 품질 문제를 감지하고 수정할 수 있습니다.커뮤니티부터 데이터 센터까지 다양한 에디션으로 구성되어 있고, 그 중 커뮤니티 에디션은 무료로 제공되고, 그 외 에디션은 연간 instance당 코드라인 수로 가격이 책정되고 다양한 기능들이 더 추가되어 있습니다. SonaQube 구조 소나큐브 플랫폼을 구성하여 4요소에..

아키텍쳐 개요 소프트웨어 아키텍처는 여러 개의 동시 뷰, 즉 관점에 따른 다양한 형태로 접근해야 합니다. 화면 좌측 상단의 거리가 소스코드 같은 저수준이라면, 화면 우측 상단의 큰 지도가 아키텍처 같은 고수준이라고 할 수 있습니다. 지도를 확대/축소하면서 현재 위치를 확인하듯이 소프트웨어도 다양한 레벨의 관점으로 시스템을 바라보면서 다룰 수 있어야 빈번한 요구사항 변경 및 버그에 대응하기 쉽고 유지보수가 수월해집니다. 기존 개발팀이 개발을 끝낸 후 그 제품 유지보수를 담당하는 개발자에게 산출물 또는 기술문서가 필요한데, 특히 이런 문서들은 프로젝트에 새로운 멤버가 들어왔을 때 기존 개발자들과 개발속도뿐만 아니라 호흡을 맞추는 데 큰 도움이 됩니다. 그러나 훌륭한 산출물이 되기 위해서는 실제 소프트웨어의 ..

소스코드 리뷰의 기법을 나누는 방법은 얼마나 정적이고 프로세스적으로 구분하느냐에 따라 화면 상단에 코드 리뷰 스펙트럼으로 구분할 수 있고, 자동화된 도구로 이루어지는 정적분석인 코드 인스펙션과 사람에 의해 수동적으로 수행되는 코드 리뷰 등으로 나눌 수 있습니다. 코드 리뷰 중 정형화된 방법으로는 주로 개발 단계 후반의 결함 발견에 집중하고, 손쉬운 방법의 측면은 결함 발견뿐 만 아니라 아이디어 회의, 팀원 간 지식 공유의 목적도 있습니다. Peer review는 두세 명이 진행하는 형태로 코드 작성자가 자신의 코드를 설명하고, 다른 사람이 아이디어를 제안하거나 결함을 발견하는 방식입니다. 주로 시니어 개발 사수가 주니어 개발자를 멘토링할 때 사용하지만, 시니어 개발자의 역량에 따라 품질이 달라질 수 있고..

지속적 통합환경 구축해야 할 큰 요소는 깃랩, 젠킨스, 소나큐브입니다. 계획 및 일감관리는 웹 인터페이스를 지원하는 설치형 깃을 사용하고, 젠킨스가 소스코드가 커밋되는 것을 감지하거나 스케줄에 따라 소스코드를 통합하고 빌드하면서 정적 분석을 하면 결과는 소나큐브 대시보드에서 확인할 수 있습니다. 이 환경을 도커를 활용하여 구축한다면 기존 방식보다 매우 빠르고 쉽게 구축할 수 있습니다. 이를 Docker-Compose로 진행해 보겠습니다. Docker-Compose.yml을 직접 작성하지 않고 만들어져서 깃허브에 올라와 있는 것을 활용하도록 하겠습니다. 화면에 있는 깃허브 레파지토리를 클론해서 사용하겠습니다. STS의 Git 플러그인 기능을 통해서 조금 전 소개했던 깃 레파지토리를 클론합니다. 다운받은 위..

Docker Compose란? Docker-Compose는 여러 개의 컨테이너를 일괄적으로 관리하는 도구입니다. 대부분의 시스템은 여러 대의 서버가 유기적으로 연계되어 마치 하나의 서비스처럼 작동합니다. 이때 다수의 컨테이너 각각을 개별적으로 다루는 것보다 여러 개를 통합적으로 관리하는 것이 효과적입니다. Docker-Compose는 도커와는 별개의 도구이지만 Docker ce for windows에서 기본적으로 제공됩니다. docker-compose.yml Docker-Compose.yml은 Docker-Compose의 구성 파일입니다. 한 파일 안에 여러 컨테이너 설정 내용을 저장합니다. 도커 애플리케이션을 위한 서비스, 네트워크, 볼륨 등을 정의합니다. 버전별로 차이점이 있으며 현재 최신 버전은 버..