이 가이드에서는 Plastic SCM이 Bugzilla, Mantis, Trac, Jira, Axosoft, VersionOne, FogBugz, Rally, Polarion, codeBeamer 등 다양한 제어 추적 툴과 통합하는 방법을 설명합니다.
이 가이드를 사용하면 Plastic SCM 커스텀 확장 프로그램을 직접 작성하는 방법도 배울 수 있습니다.
이슈 추적 시스템 구성이 완료되면 사용자는 Plastic SCM 커스텀 확장 프로그램과 Plastic SCM을 원활하게 사용할 수 있습니다. 그러면 사용자는 Plastic GUI를 통해 관련 작업 정보를 확인할 수 있습니다.
Plastic SCM 확장 프로그램은 다음과 같은 두 개의 서로 다른 작업 모드에서 사용할 수 있습니다.
이 섹션에서는 Plastic SCM과 Bugzilla의 통합을 사용하기 위해 따라야 하는 단계를 설명합니다.
이 장에서는 서버 측과 클라이언트 측에서 모두 Bugzilla 통합을 구성하는 방법을 알아봅니다.
Bugzilla 확장 기능을 설치하려면 plastic.cgi 스크립트 파일(plasticscm_install_path/client/extensions/bugzilla에 있음)을 Bugzilla 설치 폴더에 복사합니다.
서버 운영 체제에 따라 스크립트 파일의 첫 번째 줄이 변경될 수 있습니다.
#!/usr/bin/perl -wT
#!c:\perl\bin\perl.exe -wT
Windows, Linux, macOS 시스템에서 Bugzilla 통합을 어떻게 구성하는지 살펴보십시오.
다음 단계에 따라 Windows 기기의 Plastic SCM 클라이언트에 Bugzilla 확장을 구성합니다.
plastic-global-config 리포지토리를 선택합니다.
Repositories를 선택합니다.
다음 방법 중 하나를 사용하여 Linux 또는 macOS 기기의 Plastic SCM 클라이언트에 Bugzilla 확장을 구성할 수 있습니다.
$HOME/.plastic4 아래에 issuetrackers/server_port/repository 구조를 생성합니다. 여기서 repository는 다음 값 중 하나입니다.
allrepos, 즉 이슈 추적기에 연결되는 모든 리포지토리.
bugzilla.conf 예시 구성 파일을 새로 생성된 경로로 복사합니다. plasticscm_install_path/client/extensions/config_samples
/Applications/PlasticSCM.app/Contents/IssueTrackerConfigSamples
그러면 다음과 같은 구조가 됩니다.
bugzilla.conf 파일을 편집합니다.
WorkingMode 매개 변수를 편집하여 TaskOnBranch 또는 TaskOnChangeset 값 중 하나를 할당합니다.
client.conf 파일을 편집하여 다음 키를 추가합니다.
<Extensions>
<Extension AssemblyFile="plasticscm_install_path/client/extensions/bugzilla/bugzillaextension.dll" />
</Extensions>
Bugzilla Base URL: Bugzilla 서버가 설치되고 실행되는 URL을 지정합니다.User name: 필요한 경우 사용자 이름을 입력합니다.Branch prefix: 브랜치 기반 작업 모드를 사용할 경우 이 매개 변수를 지정하는 것이 좋습니다(필수는 아님). 이 브랜치 접두어는 Plastic 브랜치를 Bugzilla 작업에 바인드하는 데 사용됩니다. 이 작업 모드를 사용하면 모든 Bugzilla 작업이 새로운 브랜치 생성 시 Plastic 브랜치에 연결됩니다. 새 브랜치의 브랜치 이름은 Bugzilla에서 구성된 확장자 접두어(설정된 경우) 및 숫자 식별자와 일치해야 합니다.
브랜치 뷰에서 확장된 정보 표시 버튼(
)을 클릭하면 브랜치 관련 정보가 Plastic GUI의 오른쪽 패널에 표시됩니다. 브랜치를 선택하면 Bugzilla 작업 정보(숫자 또는 식별자, 작업 소유자, 상태, 제목 및 설명)가 Plastic SCM에 표시됩니다.
작업 창을 더블 클릭하거나 브라우저에서 이슈 열기 버튼(
)을 클릭하면 새 브라우저 창이 열리고 Bugzilla 작업에 대한 모든 정보가 표시됩니다.
작업에 연결된, 번호가 매겨진 브랜치를 Bugzilla에 대해 검사하도록 Plastic SCM 리포지토리를 설정할 수 있습니다. Bugzilla에 정의된 버그 번호가 있는 경우에만 작업 브랜치가 허용됩니다. 이 검사는 브랜치 생성 작업 시 수행되며 오직 자식 브랜치에 대해서만 이루어집니다.
리포지토리에서 브랜치 생성 검사를 설정하려면 원하는 리포지토리에 plastic-enforce-task-branch라는 속성을 생성합니다. 이 속성은 다음 중 한 가지 방법을 사용하여 생성해야 합니다.
이 속성이 생성되면 자식 브랜치가 정의된 리포지토리에서 자식 브랜치가 생성되려 할 때마다, 확장이 새 브랜치의 이름을 검사합니다. 이름이 작업 접두어로 시작하면 이름에 포함된 번호를 선택하고 일치하는 버그 번호가 있는지 Bugzilla에게 확인을 요청합니다. 그렇지 않으면 오류가 출력되고 작업이 취소됩니다.
체인지 세트 기반 작업 작업 모드로 작업하도록 Plastic SCM을 구성하려면 사용자가 이전 클라이언트 섹션에서 설명하는 대로 Bugzilla 확장을 구성하고 Plastic 체인지 세트로 이슈 바인드 옵션을 선택해야 합니다.
워크플로는 다음과 비슷합니다.
Plastic SCM - Windows - 체크인 다이얼로그 및 새 이슈 추가 옵션
Plastic SCM - Linux - 체크인 다이얼로그 및 새 이슈 추가 옵션
Plastic SCM - macOS - 체크인 다이얼로그 및 새 이슈 추가 옵션
Plastic SCM - Windows - 이슈 추가
Plastic SCM - Linux - 이슈 추가
Plastic SCM - macOS - 이슈 추가
체인지 세트가 Bugzilla 작업에 연결되면 이 정보를 Plastic SCM 체인지 세트 뷰에 표시할 수 있습니다. 확장된 정보 패널이 표시되면() 체인지 세트를 클릭하는 경우 연결된 Bugzilla 작업이 Plastic에 표시됩니다.
또한 사용자는 Bugzilla 확장 창에서 새 작업을 추가하거나 이전 작업을 삭제할 수 있습니다. 그 외에도 특정 체인지 세트에 연결된 각 작업을 더블 클릭하거나 브라우저에서 이슈 열기 버튼()을 클릭하면 새 웹 브라우저 창이 열리고 선택한 Bugzilla 작업이 표시됩니다. Bugzilla에서 사용자가 작업을 수정할 때마다 Bugzilla 확장 창에서 새로고침 버튼을 누르면 Plastic GUI에서 새 데이터가 업데이트됩니다.
이 섹션에서는 Plastic SCM과 Bugzilla의 통합을 사용하기 위해 따라야 하는 단계와 통합의 장점을 설명합니다.
이 확장은 Mantis 버전 0.19.4, 1.0.0, 1.0.8 이상과 호환됩니다.
서버 측과 클라이언트 측에서 모두 Mantis 통합을 구성하는 방법을 살펴보십시오.
Mantis 확장 기능을 설치하려면 plastic.php 스크립트 파일(plasticscm_install_path/client/extensions/mantis에 있음)을 Mantis 설치 폴더에 복사합니다.
Windows, Linux, macOS 시스템에서 Mantis 통합을 어떻게 구성하는지 살펴보십시오.
다음 단계에 따라 Windows 기기의 Plastic SCM 클라이언트에 Mantis 확장을 구성합니다.
plastic-global-config 리포지토리를 선택합니다.
Repositories를 선택합니다.
다음 방법 중 하나를 사용하여 Linux 또는 macOS 기기의 Plastic SCM 클라이언트에 Mantis 확장을 구성할 수 있습니다.
$HOME/.plastic4 아래에 issuetrackers/server_port/repository 구조를 생성합니다. 여기서 repository는 다음 값 중 하나입니다.
allrepos, 즉 이슈 추적기에 연결되는 모든 리포지토리.
mantis.conf 예시 구성 파일을 새로 생성된 경로로 복사합니다. plasticscm_install_path/client/extensions/config_samples
/Applications/PlasticSCM.app/Contents/IssueTrackerConfigSamples
그러면 다음과 같은 구조가 됩니다.
mantis.conf 파일을 편집합니다.
WorkingMode 매개 변수를 편집하여 TaskOnBranch 또는 TaskOnChangeset 값 중 하나를 할당합니다.
client.conf 파일을 편집하여 다음 키를 추가합니다.
<Extensions>
<Extension AssemblyFile="plasticscm_install_path/client/extensions/mantis/mantisextension.dll" />
</Extensions>
Mantis Base URL: Mantis 서버가 설치되고 실행되는 URL을 지정합니다.
User name: 이 필드에는 유효한 Mantis 사용자를 입력해야 합니다.
Branch prefix: 브랜치 기반 작업 모드를 사용할 경우 이 매개 변수를 지정하는 것이 좋습니다(필수는 아님). 이 브랜치 접두어는 Plastic 브랜치를 Mantis 작업에 바인드하는 데 사용됩니다. Encoding: UTF-8이 기본값이며 대부분의 언어를 지원합니다. 인코딩을 변경해야 하는 경우 이 값을 편집합니다.
브랜치 기반 작업은 기본적으로 구성된 작업 모드로, "작업별 브랜치" 패턴과 잘 동작합니다. 이 작업 모드에서는 수행할 각 작업에 대한 새 브랜치가 생성됩니다.
평소와 마찬가지로 Mantis에서 이슈를 생성하는 첫 번째 단계는 일반적으로 프로젝트 매니저가 처리합니다. "이슈 보고" 옵션을 클릭하면 처리할 새 이슈에 대한 정보를 담을 다이얼로그가 열리고, 담을 정보로는 제목, 설명, 심각도 등이 있습니다.
이슈가 생성되면 Mantis는 이슈에 번호를 할당합니다. 이 경우, 아래 그림처럼 Mantis는 번호 4를 작업에 할당합니다. 사용자는 상태에 따라 이슈가 다른 색상으로 표시되는 이슈 목록에서 이슈를 선택하고 해당 상태를 변경할 수 있으므로 이슈 4는 신규에서 할당됨으로 전환됩니다.
다음 단계로, 작업에 할당된 개발자가 새 브랜치를 생성해야 합니다. 이 작업은 다음 이미지에 표시된 것처럼 부모 브랜치를 오른쪽 클릭하고 자식 브랜치 생성 옵션을 선택하면 되는 간단한 작업입니다.
Mantis에서 새 브랜치를 이슈에 연결하려면 개발자가 해당 브랜치의 브랜치 접두어 뒤에 동일한 Mantis 번호(이 경우 4)를 부여해야 합니다.
이제 사용자가 브랜치 뷰의 확장된 정보 패널()에서 특정 브랜치에 연결된 이슈에 대한 정보를 확인할 수 있습니다.
사용자가 브라우저에서 이슈 열기 버튼()을 클릭하거나 Mantis 작업을 더블 클릭하면 관련 브랜치 이슈가 담긴 브라우저 창이 열립니다. 사용자가 상태 또는 다른 이슈 필드를 변경하는 경우, Mantis 확장을 새로 고치면 새 정보가 표시됩니다.
체인지 세트 기반 작업 작업 모드로 작업하도록 Plastic SCM을 구성하려면 사용자가 이전 클라이언트 섹션에서 설명된 바와 같이 Mantis 확장을 구성하고 Plastic 체인지 세트로 이슈 바인드 옵션을 선택해야 합니다.
워크플로는 다음과 비슷합니다.
Plastic SCM - Windows - 체크인 다이얼로그 및 새 이슈 추가 옵션
Plastic SCM - Linux - 체크인 다이얼로그 및 새 이슈 추가 옵션
Plastic SCM - macOS - 체크인 다이얼로그 및 새 이슈 추가 옵션
Plastic SCM - Windows - 이슈 추가
Plastic SCM - Linux - 이슈 추가
Plastic SCM - macOS - 이슈 추가
Mantis에서 체인지 세트가 이슈 또는 작업에 연결되면 이 정보를 Plastic SCM 체인지 세트 뷰에 표시할 수 있습니다. 확장된 정보 패널이 표시되면() 체인지 세트를 클릭하는 경우 연결된 Mantis 작업이 Plastic에 표시됩니다.
사용자는 Mantis 확장 창에서 새 작업을 추가하거나 이전 작업을 삭제할 수 있습니다. 그 외에도 특정 체인지 세트에 연결된 각 작업을 더블 클릭하거나 브라우저에서 이슈 열기 버튼()을 클릭하면 새 웹 브라우저 창이 열리고 선택한 Mantis 작업이 표시됩니다. Mantis에서 사용자가 작업을 수정할 때마다 Mantis 확장 창에서 새로고침 버튼을 누르면 Plastic GUI에서 새 데이터가 업데이트됩니다.
이 섹션에서는 Plastic SCM과 Trac의 통합을 사용하기 위해 따라야 하는 단계를 설명합니다. 통합의 장점을 설명합니다.
이 확장은 Trac 버전 0.10부터 호환됩니다.
이 장에서는 서버 측과 클라이언트 측에서 모두 Trac 통합을 구성하는 방법을 알아봅니다.
Trac 확장 기능을 설치하려면 Trac 서버에 XMLRPC 플러그인이 설치되어 있어야 합니다. 다운로드하고, 설치하고, 올바르게 설치되었는지 확인하는 방법에 대한 정보는 이 링크에서 살펴볼 수 있습니다.
Trac 관리 툴을 사용하여 확장을 사용할 사용자에게 XML RPC 권한을 제공합니다. 이 권한이 "익명" 사용자에게 할당되는 경우 모든 사용자가 이 확장을 사용할 수 있습니다.
Trac 확장을 사용하는 경우 여러 서버 구성 기능을 고려해야 합니다.
Windows, Linux, macOS 시스템에서 Trac 통합을 구성하는 방법을 살펴보십시오.
다음 단계에 따라 Windows 기기의 Plastic SCM 클라이언트에 Trac 확장을 구성합니다.
plastic-global-config 리포지토리를 선택합니다.
Repositories를 선택합니다.
다음 방법 중 하나를 사용하여 Linux 또는 macOS 기기의 Plastic SCM 클라이언트에 Trac 확장을 구성할 수 있습니다.
$HOME/.plastic4 아래에 issuetrackers/server_port/repository 구조를 생성합니다. 여기서 repository는 다음 값 중 하나입니다.
allrepos, 즉 이슈 추적기에 연결되는 모든 리포지토리.
trac.conf 예시 구성 파일을 새로 생성된 경로로 복사합니다. plasticscm_install_path/client/extensions/config_samples
/Applications/PlasticSCM.app/Contents/IssueTrackerConfigSamples
그러면 다음과 같은 구조가 됩니다.
trac.conf 파일을 편집합니다.
WorkingMode 매개 변수를 편집하여 TaskOnBranch 또는 TaskOnChangeset 값 중 하나를 할당합니다.
client.conf 파일을 편집하여 다음 키를 추가합니다.
<Extensions>
<Extension AssemblyFile="plasticscm_install_path/client/extensions/trac/tracextension.dll" />
</Extensions>
Base Trac URL: Trac 서버가 설치되고 실행되는 URL을 지정합니다.
This server requires authentication, User name 및 Password: Trac 서버가 기본 인증 사용자/비밀번호 모드로 구성된 경우 This server requires authentication 체크박스를 활성화하고 Trac 서버에 대해 인증할 자격 증명을 입력합니다.
Branch prefix: 브랜치 기반 작업 모드를 사용할 경우 이 매개 변수를 지정하는 것이 좋습니다(필수는 아님). 이 브랜치 접두어는 Plastic 브랜치를 Trac 작업에 바인드하는 데 사용됩니다. 기본적으로 구성된 작업 모드는 브랜치 기반 작업 모드로, "작업별 브랜치" 패턴과 잘 동작합니다. 이 작업 모드에서는 수행할 각 작업에 대한 새 브랜치가 생성됩니다.
평소와 같이 첫 번째 단계로 Trac에서 이슈를 생성합니다. 이 작업은 일반적으로 프로젝트 매니저가 처리합니다. "새 티켓" 옵션을 클릭하면 처리할 새 이슈에 대한 정보를 포함할 다이얼로그가 열립니다. 제목, 설명, 요약 등의 정보를 포함하게 됩니다.
작업 또는 티켓이 생성되면 Trac은 번호를 할당합니다(아래 그림 예시의 경우 번호 4).
이제 개발자는 할당된 작업을 사용해야 합니다. 따라서 아래 이미지에 표시된 것처럼 새 브랜치를 생성합니다(간단히 부모 브랜치를 오른쪽 클릭하고 자식 브랜치 생성 옵션 선택). Trac에서 새 브랜치를 이슈에 연결하려면 이슈의 이름이 Trac 확장에서 구성된 브랜치 접두어(정의된 경우) 및 Trac 이슈 번호(이 경우 이슈 번호 4)와 일치해야 합니다. 따라서 브랜치 접두어가 'scm'으로 설정된 경우 scm004가 Trac 티켓 #4와 연결됩니다.
확장된 정보 표시버튼()을 클릭하면 브랜치에 대한 확장된 정보가 표시됩니다. 브랜치 뷰에서 브랜치를 선택하면 오른쪽 창에 관련 작업/결함 정보(번호, 작업이 할당된 소유자 또는 개발자, 제목, 코멘트)가 표시됩니다.
Trac 정보 작업을 더블 클릭하거나 브라우저에서 이슈 열기 버튼()을 누르면 관련 브랜치 작업을 보여 주는 새 브라우저 창이 열리고 Trac 작업에 대한 모든 정보가 표시됩니다.
체인지 세트 기반 작업 작업 모드로 작업하도록 Plastic SCM을 구성하려면, 이전 클라이언트 섹션의 설명대로 사용자가 Trac 확장을 구성하고 Plastic 체인지 세트로 이슈 바인드 옵션을 선택해야 합니다.
워크플로는 다음과 비슷합니다.
Plastic SCM - Windows - 체크인 다이얼로그 및 새 이슈 추가 옵션
Plastic SCM - Linux - 체크인 다이얼로그 및 새 이슈 추가 옵션
Plastic SCM - macOS - 체크인 다이얼로그 및 새 이슈 추가 옵션
Plastic SCM - Windows - 이슈 추가
Plastic SCM - Linux - 이슈 추가
Plastic SCM - macOS - 이슈 추가
Trac에서 체인지 세트가 티켓 또는 작업에 연결되면 이 정보를 Plastic SCM 체인지 세트 뷰에 표시할 수 있습니다. 확장된 정보 패널이 표시되면() 체인지 세트를 클릭하는 경우 연결된 Trac 작업이 Plastic에 표시됩니다.
사용자는 Trac 확장 창에서 새 작업을 추가하거나 이전 작업을 삭제할 수 있습니다. 그 외에도 특정 체인지 세트에 연결된 각 작업을 더블 클릭하거나 브라우저에서 이슈 열기 버튼()을 클릭하면 새 웹 브라우저 창이 열리고 선택한 Trac 작업이 표시됩니다. Trac에서 사용자가 작업을 수정할 때마다 Trac 확장 창에서 새로고침 버튼을 누르면 Plastic GUI에서 새 데이터가 업데이트됩니다.
이 섹션에서는 Jira와 Plastic SCM의 연동을 설정하는 데 필요한 단계를 설명합니다.
이 장에서는 서버 측과 클라이언트 측에서 모두 Jira 통합을 구성하는 방법을 알아봅니다.
새 필드는 기본적으로 비어 있으며, 내용이 있을 때까지 구성된 화면에 표시되지 않습니다.
Jira Cloud에서는 '원격 API 호출 수락' 옵션이 기본적으로 활성화되어 있습니다. 따라서 Jira Cloud 사용자라면 이 단계를 건너뛰어도 됩니다.
이러한 단계가 완료되면 Jira 서버는 Plastic SCM 통합을 수락할 수 있습니다.
Windows, Linux, macOS 시스템에서 Jira 통합을 구성하는 방법을 살펴보십시오.
다음 단계에 따라 Windows 기기의 Plastic SCM 클라이언트에 Jira 확장을 구성합니다.
plastic-global-config 리포지토리를 선택합니다.
Repositories를 선택합니다.
다음 방법 중 하나를 사용하여 Linux 또는 macOS 기기의 Plastic SCM 클라이언트에 Jira 확장을 구성할 수 있습니다.
$HOME/.plastic4 아래에 issuetrackers/server_port/repository 구조를 생성합니다. 여기서 repository는 다음 값 중 하나입니다.
allrepos, 즉 이슈 추적기에 연결되는 모든 리포지토리.
jira.conf 예시 구성 파일을 새로 생성된 경로로 복사합니다. plasticscm_install_path/client/extensions/config_samples
/Applications/PlasticSCM.app/Contents/IssueTrackerConfigSamples
그러면 다음과 같은 구조가 됩니다.
jira.conf 파일을 편집합니다.
WorkingMode 매개 변수를 편집하여 TaskOnBranch 또는 TaskOnChangeset 값 중 하나를 할당합니다.
client.conf 파일을 편집하여 다음 키를 추가합니다.
<Extensions>
<Extension AssemblyFile="plasticscm_install_path/client/extensions/jira/jiraextension.dll" />
</Extensions>
Host: Jira 서버가 있는 URL을 지정합니다. URL에는 Jira 서버가 실행되는 포트가 포함되어야 합니다.
User name 및 Password: Jira에 로그인하고 변경사항을 기록하는 데 사용되는 Jira 자격 증명을 지정합니다.
Jira Cloud를 사용하는 경우 User name은 계정의 이메일 주소여야 하며 Password는 API 토큰이어야 합니다. 공식 문서에서 Atlassian Cloud 계정용 API 토큰을 생성하는 방법을 확인할 수 있습니다.
Branch prefix: 브랜치 기반 작업 모드를 사용할 경우 이 매개 변수를 지정하는 것이 좋습니다(필수는 아님). 이 브랜치 접두어는 Plastic 브랜치를 Jira 작업에 바인드하는 데 사용됩니다. Project Key: 이슈가 Plastic 브랜치와 관련될 Jira 프로젝트의 키를 지정합니다.
Custom Field ID: 이 매개 변수는 Jira 작업에 Plastic 체크인 정보를 기록하는 데 사용할 커스텀 필드의 식별자입니다. 이 필드는 필드 생성 시 Jira에서 할당한 커스텀 필드 ID를 추가하기 위한 것입니다.
차세대 프로젝트는 이 필드를 지원하지 않습니다.
Custom Field ID를 공백으로 유지하여 코멘트로 추가되는 체크인 정보가 입력되도록 합니다.
Use LDAP credentials if available: Plastic SCM 클라이언트 인증 모드가 LDAP인 경우 이 매개 변수를 검사하여 해당 자격 증명을 Jira에 로그인하는 데 재사용하도록 Jira 확장을 구성할 수 있습니다. 이 기능이 작동하려면 Plastic SCM 서버와 Jira 모두 동일한 LDAP 사용자 디렉터리를 공유해야 한다는 점에 유의하시기 바랍니다.
Use default proxy credentials: 모든 Jira 확장 연결에 대해 프록시 자격 증명을 기본 자격 증명으로 자동 설정합니다.
Issue query limit: 이 매개 변수는 브랜치 생성 다이얼로그에서 반환된 결과의 최대 개수를 수동으로 조정하는 데 사용됩니다. Resolved issue states: '해결됨'으로 간주되는 상태 이름을 쉼표로 구분된 목록으로 나타냅니다. Issue types: Jira 확장이 가져오는 이슈를 유형으로 필터링할 수 있습니다. 이슈 유형 목록을 쉼표로 구분하여 입력하면 됩니다. 예를 들어 Plastic SCM에서 버그 또는 작업 이슈만 보려는 경우 나머지는 제외되어 유용합니다. jira.conf 파일에 붙여 넣으면 됩니다.
Name=Issue types;Value=Bug,Task;Type=Text;IsGlobal=False
Fields mapping: 브랜치 또는 체인지 세트 뷰에 있는 작업 정보 패널에 표시되는 Jira 이슈의 필드를 매핑할 수 있습니다. Status transition: 체인지 세트 코멘트에 따라 연결된 이슈의 상태를 변경할 수 있습니다. 이 기능은 브랜치와 체인지 세트에 이슈를 바인딩합니다. 기본적으로 구성된 작업 모드는 브랜치 기반 작업 모드로, "작업별 브랜치" 패턴과 잘 동작합니다. 이 작업 모드에서는 수행할 각 작업에 대한 새 브랜치가 생성됩니다.
Plastic SCM과 Jira 확장을 사용하려면 이슈 추적 시스템에서 "이슈 생성" 옵션을 클릭하고 새 이슈 관련 데이터(예: 이름, 관련 프로젝트, 요약)를 입력하여 작업을 생성해야 합니다.
Jira는 새로 생성된 이슈에 번호를 할당하며, 이 번호는 해당 작업을 수행할 때 Plastic 브랜치에 부여되는 것과 동일한 번호로, 지금은 이슈 번호 1을 생성합니다.
그런 다음 해당 이슈가 할당된 개발자는 관련 작업을 시작합니다. Plastic SCM GUI 클라이언트를 사용하여 새 브랜치를 생성할 것입니다. 새 브랜치를 생성하여 Jira에 연결하려면 두 가지 옵션을 사용할 수 있습니다.
브랜치 뷰에서 확장된 정보 표시 버튼()을 클릭하면 브랜치 관련 정보가 Plastic GUI의 오른쪽 패널에 표시됩니다. Plastic 브랜치를 선택하면 Jira 이슈 정보가 표시됩니다.
작업을 더블 클릭하거나 브라우저에서 이슈 열기 버튼()을 누르면 관련 브랜치 이슈를 보여 주는 새 브라우저 창이 열리고 Jira 작업에 대한 모든 정보가 표시됩니다. 사용자가 이슈 필드를 변경하는 경우, Jira 확장 패널의 새로고침 버튼을 클릭하면 새 정보가 표시됩니다.
체인지 세트 기반 작업 작업 모드로 작업하도록 Plastic SCM을 구성하려면 사용자가 이전 클라이언트 섹션에서 설명된 바와 같이 Jira 확장을 구성하고 Plastic 체인지 세트로 이슈 바인드 옵션을 선택해야 합니다.
워크플로는 다음과 비슷합니다.
Plastic SCM - Windows - 체크인 다이얼로그 및 새 이슈 추가 옵션
Plastic SCM - Linux - 체크인 다이얼로그 및 새 이슈 추가 옵션
Plastic SCM - macOS - 체크인 다이얼로그 및 새 이슈 추가 옵션
Plastic SCM - Windows - 이슈 추가
Plastic SCM - Linux - 이슈 추가
Plastic SCM - macOS - 이슈 추가
Jira에서 체인지 세트가 이슈 또는 작업에 연결되면 이 정보를 Plastic SCM 체인지 세트 뷰에 표시할 수 있습니다. 확장된 정보 패널이 표시되면() 체인지 세트를 클릭하여 연결된 Jira 이슈를 표시합니다.
또한 사용자는 Jira 확장 정보에서 새 작업을 추가하거나 이전 작업을 삭제할 수 있습니다. 그 외에도 특정 체인지 세트에 연결된 각 이슈를 더블 클릭하거나 브라우저에서 이슈 열기 버튼()을 클릭하면 새 웹 브라우저 창이 열리고 선택한 Jira 작업이 표시됩니다. 작업 추적 툴에서 사용자가 이슈를 수정할 때마다 Jira 확장 창에서 새로고침 버튼을 누르면 Plastic GUI에서 새 데이터가 업데이트됩니다.
Plastic SCM 내에서 브랜치 또는 체인지 세트에 바인드된 Jira 데이터를 표시할 수 있을 뿐만 아니라 통합을 통해 Jira 내부에서 수정된 항목에 대한 기록도 유지할 수 있습니다. 변경사항이 체크인되고 통합이 활성화되면 Jira에서는 브랜치 기반 작업 또는 체인지 세트 기반 작업 작업 모드를 사용하여 "Plastic SCM" 커스텀 필드에 영향을 받는 항목을 표시합니다.
또한 Plastic SCM에서는 Jira 멀티 프로젝트 구성이 허용됩니다. 이를 통해 모든 브랜치에 전역 프로젝트 키를 정의하지 않고, 브랜치별로 관련된 작업의 프로젝트 키를 명시적으로 포함시킬 수 있습니다.
Jira 서버의 구성이 완료되면 멀티 프로젝트 구성을 지원할 Plastic SCM 클라이언트를 구성해야 합니다.
Plastic SCM 클라이언트에 Jira 확장을 구성하려면 Plastic SCM GUI의 기본 창에 있는 기본 설정 탭을 클릭합니다. 새 다이얼로그 창이 열립니다. 이슈 추적 탭을 클릭하고 이 이슈 추적 시스템으로 바인드 라디오 버튼을 선택하고 Atlassian Jira를 선택합니다.
jira.conf 파일에서 필요한 값을 업데이트해야 합니다.
프로젝트와 작업은 Jira에서 생성되어야 합니다.
이제 Plastic SCM 브랜치를 생성합니다. Jira 작업과 관련된 브랜치를 식별하기 위해 "JIRA_" 접두어를 선택합니다.
멀티 프로젝트 구성을 사용할 때는 각 프로젝트가 어떤 브랜치와 관련이 있는지 구분해야 합니다. 아래 그림에서와 같이 Plastic SCM 브랜치의 이름을 지정할 때는 스키마 branchPrefix_projectShortName-taskID를 사용합니다.
예를 들어, Jira 작업 RI-1의 브랜치 이름은 JIRA_RI-1이 되고, Jira 프로젝트 FG(Forms generator)의 경우 JIRA_FG-1이 됩니다.
Jira 확장은 Plastic SCM의 브랜치 또는 체인지 세트 뷰에 있는 작업 정보 패널에 표시되는 Jira 이슈의 필드 매핑을 허용합니다.
Jira 필드 매핑 기능을 정의하려면 매개 변수 필드 매핑을 구성해야 합니다. 구성하기 위해 Plastic SCM GUI의 기본 창에 있는 기본 설정 탭을 클릭하고 Jira 확장 구성을 엽니다. 그런 다음 이슈 추적 탭을 누릅니다. 필드 매핑 구성 매개 변수가 보일 때까지 매개 변수 목록을 아래로 내립니다.
이 매개 변수에는 '|'(수직 바) 문자로 구분되는 필드 이름 쌍(from->to)이 저장됩니다. 매개 변수 구문은 다음과 같습니다.
[ jira_field_name -> plastic_property_name [ | jira_field_name -> plastic_property_name [ | ... ] ] ]
jira.conf 파일의 필수 필드를 업데이트해야 합니다.
다음은 유효한 Jira 필드 매핑 구성의 예입니다.
issue.Fields.Project.Name->Description|issue.Fields.Reporter.Name->Owner|issue.Fields.Description->Title
이 경우, 확장된 정보 패널 "Atlassian Jira 확장"에 표시되는 값은 다음과 같습니다. 표시된 설명에는 프로젝트 키가 포함되고, 표시된 소유자는 이슈를 생성한 Jira 사용자가 되고, 표시된 제목은 Jira 이슈에 대한 설명이 됩니다.
필드 이름 쌍 "from->to"에서 to 속성은 plastic_property_name이 참조하는 Plastic SCM 필드를 설명합니다. 다음은 확장된 정보 패널에 있는 사용 가능한 Plastic SCM 필드의 목록입니다.
from 속성은 Jira 이슈(jira_field_name)의 필드를 설명합니다. 이 필드의 값은 위에 설명한 바와 같이 to 필드로 읽어 들입니다. Jira 확장의 from 속성에 대하여 사용 가능한 필드의 목록이 아래 테이블에 자세히 나와 있습니다.
from 필드 값 |
필드 데이터 형식 |
|---|---|
| issue.Fields.Assignee.Name | 문자열 |
| issue.Fields.AttachmentNames | String[] |
| issue.Fields.ComponentNames | String[] |
| issue.Fields.Created | DateTime |
| issue.Fields.Description | 문자열 |
| issue.Fields.DueDate | DateTime |
| issue.Fields.Environment | 문자열 |
| issue.Key | 문자열 |
| issue.Fields.Priority.Name | 문자열 |
| issue.Fields.Project.Name | 문자열 |
| issue.Fields.Reporter.Name | 문자열 |
| issue.Fields.Resolution | 문자열 |
| issue.Fields.Status.Name | 문자열 |
| issue.Fields.Summary | 문자열 |
| issue.Fields.Issuetype.Name | 문자열 |
| issue.Fields.Updated | DateTime |
| issue.Fields.Votes.Number | 긴 모드 |
다음 샘플 매핑에서와 같이 customFieldValues 조정값을 사용하여 커스텀 Jira 필드의 값을 이용할 수 있습니다.
customFieldValues[10000]->Description
[ ] 간의 색인은 이전 섹션에 나와 있는 것처럼 Jira에서 가져올 수 있는 커스텀 필드 id입니다. 샘플 10000에는 커스텀 필드 id 번호만 제공되면 됩니다.
Jira 이슈 추적기 확장 프로그램은 체인지 세트 코멘트를 기반으로 관련 이슈의 상태를 브랜치/체인지 세트로 변경할 수 있습니다.
이슈의 상태를 변경하려면 고유한 키워드-상태 매핑을 정의해야 합니다. 키워드가 체인지 세트 코멘트에 있는 경우, 이슈 상태가 정의된 상태로 변경됩니다.
매핑 형식은 다음과 같습니다.
KEY-VALUE|KEY-VALUE
예:
[FIXED]-Ready for QA|[WONTFIX]-Done
위의 예에서는 체인지 세트의 코멘트에 키워드 [FIXED](괄호 포함)가 있는 경우, 이슈 상태가 Ready for QA로 변경된다고 되어 있습니다.
이 기능은 브랜치와 체인지 세트에 이슈를 바인딩합니다.
Jira 워크플로에서 상태 간 전환을 허용해야 합니다.
상태 전환 허용을 위해 Plastic SCM 커스텀 필드 ID를 설정할 필요는 없습니다.
Windows, Linux, macOS 시스템에서 상태 전환 기능을 구성하는 방법을 알아보시기 바랍니다.
jira.conf 파일을 엽니다.
Value 매개 변수의 텍스트를 필요한 KEY-VALUE 쌍으로 바꿉니다.
Name=Status transitions;Value=[FIXED]-Ready for QA|[WONTFIX]-Done;Type=Text;IsGlobal=True
Plastic SCM과 Axosoft의 통합을 사용하려면 이 섹션의 단계를 따르십시오.
이 확장은 Axosoft 버전 14 이상과 호환됩니다.
이 장에서는 서버 측과 클라이언트 측에서 모두 Axosoft 통합을 구성하는 방법을 알아봅니다.
Axosoft 확장 기능을 설치하려면 Plastic SCM에 Axosoft 서버 기본 URL을 제공해야 합니다.
Axosoft 통합을 구성하기 위해 Plastic SCM 클라이언트에 필요한 다른 두 구성 매개 변수는 client-id 및 client-secret 매개 변수입니다. 이 값을 얻으려면 먼저 "툴" 메뉴 아래 "시스템 옵션" 옵션으로 이동합니다.
"시스템 설정" 창에서 "Axosoft API 설정" 탭을 클릭합니다. 이 뷰에서 "API 활성화" 체크박스를 선택하고 "API 키 관리" 버튼을 클릭합니다.
새 창에서 "추가" 버튼을 클릭하여 Axosoft와 Plastic SCM의 통합을 식별하고 인증하는 데 사용할 두 개의 값을 가져옵니다. "애플리케이션 이름"을 입력하고 "클라이언트 ID" 및 "클라이언트 비밀" 값을 복사한 후 "저장" 버튼을 클릭합니다.
API 키가 저장되면 이제 커스텀 필드를 생성하여 Plastic SCM이 Axosoft 이슈와 관련된 체크인 작업이 있을 때마다 이루어진 모든 변경사항을 기록하게 합니다.
이 작업을 허용하려면 새 커스텀 필드를 Axosoft에 생성해야 합니다. "툴" 메뉴로 이동하고 "필드" 하위 메뉴에서 "커스텀 필드" 옵션을 선택하여 이 작업을 처리합니다.
새 창의 "버그" 탭에서 "추가" 버튼을 클릭한 후, 새 커스텀 필드에 Plastic SCM을 입력하고 "큰 텍스트" 유형을 선택합니다.
다음 섹션에서 Plastic SCM 클라이언트 구성에 사용할 새 커스텀 필드를 저장합니다.
Axosoft 서버 구성에 대한 자세한 내용은 Axosoft 설치 시 포함된 매뉴얼이나 Axosoft 웹사이트를 참조하시기 바랍니다.
Windows, Linux, macOS 시스템에서 Axosoft 통합을 구성하는 방법을 살펴보십시오.
다음 단계에 따라 Windows 기기의 Plastic SCM 클라이언트에 Axosoft 확장을 구성합니다.
plastic-global-config 리포지토리를 선택합니다.
Repositories를 선택합니다.
다음 방법 중 하나를 사용하여 Linux 또는 macOS 기기의 Plastic SCM 클라이언트에 Axosoft 확장을 구성할 수 있습니다.
$HOME/.plastic4 아래에 issuetrackers/server_port/repository 구조를 생성합니다. 여기서 repository는 다음 값 중 하나입니다.
allrepos, 즉 이슈 추적기에 연결되는 모든 리포지토리.
ontime.conf 예시 구성 파일을 새로 생성된 경로로 복사합니다. plasticscm_install_path/client/extensions/config_samples
/Applications/PlasticSCM.app/Contents/IssueTrackerConfigSamples
그러면 다음과 같은 구조가 됩니다.
ontime.conf 파일을 편집합니다.
WorkingMode 매개 변수를 편집하여 TaskOnBranch 또는 TaskOnChangeset 값 중 하나를 할당합니다.
client.conf 파일을 편집하여 다음 키를 추가합니다.
<Extensions>
<Extension AssemblyFile="plasticscm_install_path/client/extensions/ontime/ontimeextension.dll" />
</Extensions>
Axosoft Root URL: 이전에 서버 주제에서 설명한 대로 Plastic SCM Axosoft 확장이 작동하려면 이 값이 필요합니다.
User 및 Password: 각 Plastic SCM 사용자에게는 Axosoft 계정이 있어야 하며 Axosoft 자격 증명을 사용하여 Plastic이 Axosoft 서버와 연결할 수 있도록 해야 합니다.
Branch prefix: Plastic SCM이 브랜치 기반 작업 모드를 사용하도록 구성된 경우 사용자는 여러 브랜치 접두어를 구성하여 이를 여러 Axosoft 객체와 바인드할 수 있습니다. 예를 들어 사용자가 Axosoft 결함과 Axosoft 작업 간 매핑을 사용하는 경우 이름이 접두어 def로 시작하는 브랜치는 Axosoft 결함으로, 이름이 접두어 task로 시작하는 브랜치는 Axosoft 작업으로 연결됩니다. Client ID 및 Client Secret: 해당 필드에는 Axosoft 관리 패널에서 생성된 토큰을 입력해야 합니다. 자세한 내용은 서버 주제를 참조하시기 바랍니다.
Plastic SCM custom field: 이 매개 변수는 Axosoft에서 생성된 커스텀 필드로, Plastic 체크인 정보 기록에 사용됩니다.
Pending status list: 쉼표로 구분된 값 문자열을 입력하는 방식으로 이 필드를 사용하여 "대기 중"으로 간주되는 상태 목록을 편집할 수 있습니다.
기본적으로 구성된 작업 모드는 브랜치 기반 작업 모드로, "작업별 브랜치" 패턴과 잘 동작합니다. 이 작업 모드에서는 수행할 각 작업에 대한 새 브랜치가 생성됩니다.
Plastic SCM과 Axosoft 확장을 사용하려면 이슈 추적 시스템에서 결함을 생성해야 합니다. 아래 이미지의 설명대로 "추가" 메뉴를 클릭하고 "전부 추가" 옵션을 선택하여 이 작업을 처리합니다.
"버그 추가" 창에서 새 작업 이름, 우선 순위, 상태, 할당된 엔지니어 등의 정보를 입력해야 합니다. 새 결함이 저장되면 Axosoft는 해당 작업을 수행하기 위해 Plastic SCM 브랜치 생성 시 할당된 개발자가 사용하는 ID 번호를 결함에 부여합니다.
그런 다음 해당 이슈에 할당된 개발자는 Plastic SCM GUI 클라이언트를 통해 새 브랜치를 생성하여 작업을 시작합니다. 새 브랜치의 이름은 Plastic SCM Axosoft 확장에서 구성된 브랜치 접두어(정의된 경우) 및 그 뒤에 Axosoft에서 연결을 위해 할당한 이슈 번호와 일치해야 합니다.
브랜치 뷰에서 확장된 정보 표시 버튼()을 클릭하면 다음 스크린샷에 표시된 것처럼 브랜치 관련 정보가 GUI의 오른쪽에 표시됩니다. 브랜치를 선택하면 Axosoft 결함에 대한 자세한 정보(이름, 소유자, 상태, 제목, 설명)가 표시됩니다.
작업을 더블 클릭하거나 브라우저에서 이슈 열기 버튼()을 누르면 관련 브랜치 작업을 보여 주는 새 웹 브라우저 창이 열리고 Axosoft 작업에 대한 모든 정보가 표시됩니다. 사용자가 상태 또는 다른 이슈 필드를 변경하는 경우, Axosoft 확장의 새로고침 버튼을 클릭하면 새 정보가 표시됩니다.
체인지 세트 기반 작업 작업 모드로 작업하도록 Plastic SCM을 구성하려면 사용자가 이전 클라이언트 섹션의 설명대로 Axosoft 확장을 구성하고 Plastic 체인지 세트로 이슈 바인드 옵션을 선택해야 합니다.
워크플로는 다음과 비슷합니다.
Plastic SCM - Windows - 체크인 다이얼로그 및 새 이슈 추가 옵션
Plastic SCM - Linux - 체크인 다이얼로그 및 새 이슈 추가 옵션
Plastic SCM - macOS - 체크인 다이얼로그 및 새 이슈 추가 옵션
Plastic SCM - Windows - 이슈 추가
Plastic SCM - Linux - 이슈 추가
Plastic SCM - macOS - 이슈 추가
체인지 세트가 Axosoft 결함 또는 작업에 연결되면 확장 정보()가 체인지 세트 뷰에 표시됩니다. 또한 사용자는 Axosoft 확장 창을 통해 새 작업을 추가하거나 이전 작업을 삭제할 수 있으며, 각 이슈를 더블 클릭하거나 브라우저에서 이슈 열기 버튼()을 클릭하면 관련 Axosoft 이슈를 보여 주는 새 웹 브라우저 창이 열립니다. 작업 추적 툴에서 사용자가 이슈를 수정할 때마다 Axosoft 확장 창에서 새로고침 버튼을 누르면 Plastic GUI에서 새 데이터가 업데이트됩니다.
Plastic SCM과 통합된 브랜치 및 체인지 세트와 관련된 이슈에 대한 정보를 표시하는 것 외에도 이 확장은 관련된 이슈가 체크인될 때마다 Axosoft에 기록합니다.
따라서 사용자가 각 체크인 작업이 Axosoft 작업에 어떻게 등록되었는지 확인할 수 있습니다.
이 섹션에서는 Plastic SCM과 VersionOne의 통합을 사용하는 단계를 설명합니다.
이 확장은 VersionOne 버전 7.2 이상과 호환됩니다.
이 장에서는 서버 측과 클라이언트 측에서 모두 VersionOne 통합을 구성하는 방법을 알아봅니다.
Plastic SCM VersionOne 확장 구성의 경우 서버 측에서는 변경할 필요가 없습니다.
Windows, Linux, macOS 시스템에서 VersionOne 통합을 구성하는 방법을 살펴보십시오.
Windows 기기의 Plastic SCM 클라이언트에 VersionOne 확장을 구성하는 방법은 다음과 같습니다.
plastic-global-config 리포지토리를 선택합니다.
Repositories를 선택합니다.
다음 방법 중 하나를 사용하여 Linux 또는 macOS 기기의 Plastic SCM 클라이언트에 VersionOne 확장을 구성할 수 있습니다.
$HOME/.plastic4 아래에 issuetrackers/server_port/repository 구조를 생성합니다. 여기서 repository는 다음 값 중 하나입니다.
allrepos, 즉 이슈 추적기에 연결되는 모든 리포지토리.
versionone.conf 예시 구성 파일을 새로 생성된 경로로 복사합니다. plasticscm_install_path/client/extensions/config_samples
/Applications/PlasticSCM.app/Contents/IssueTrackerConfigSamples
그러면 다음과 같은 구조가 됩니다.
versionone.conf 파일을 편집합니다.
WorkingMode 매개 변수를 편집하여 TaskOnBranch 또는 TaskOnChangeset 값 중 하나를 할당합니다.
client.conf 파일을 편집하여 다음 키를 추가합니다.
<Extensions>
<Extension AssemblyFile="plasticscm_install_path/client/extensions/versionone/versiononeextension.dll" />
</Extensions>
Base URL: VersionOne 서버가 설치되고 실행되는 URL을 지정합니다.
User 및 Password: Use integrated authentication 옵션이 선택되어 있지 않은 경우, 이 필드에는 유효한 VersionOne 사용자를 입력해야 합니다.
Defect prefix, Task prefix, Test prefix, Story prefix: 연결할 수 있는 VersionOne 객체는 결함, 작업, 테스트, 스토리입니다. Use integrated authentication: 이 옵션은 Windows 도메인 사용자 인증 확인 여부를 Plastic SCM에 전달합니다.
기본 작업 모드는 브랜치 기반 작업 모드로, 각 작업에 대해 새 브랜치가 생성되는 "작업별 브랜치" 패턴에 사용됩니다.
Plastic SCM과 VersionOne 확장을 사용하기 위한 첫 단계로 VersionOne에서 작업을 생성합니다. 이 작업은 일반적으로 프로젝트 매니저가 VersionOne 웹 인터페이스에서 "결함 추가", "이슈 추가", "백로그 항목 추가", "요청 추가" 바로가기를 클릭하여 처리합니다. 새 작업 데이터를 입력하기 위한 새 다이얼로그 창이 열립니다. VersionOne은 작업에 번호(1000~)를 할당합니다. 브랜치 이름에는 해당 작업 유형에 대해 구성된 접두어와 VersionOne에서 할당된 번호가 포함되어야 하므로 번호에 매우 유의해야 합니다.
이슈가 생성되면 VersionOne은 이슈에 번호를 할당합니다. 다음 그림에서 생성한 항목의 목록을 볼 수 있습니다.
그런 다음 작업이 할당된 개발자는 관련 작업을 시작합니다. 다음 이미지에서 보이는 대로 새 브랜치를 만들어야 하며(부모 브랜치를 오른쪽 클릭하고 자식 브랜치 생성옵션 선택), 새 브랜치를 VersionOne의 작업에 연결하려면 브랜치에 동일한 번호를 부여해야 합니다(주의: 이 숫자는 항상 1000보다 큽니다).
이제 사용자가 브랜치 뷰의 확장된 정보()로 이동하고 브랜치를 선택하여 이슈에 대한 정보를 확인할 수 있습니다. 그러면 작업 번호, 소유자, 상태 등의 VersionOne 확장 정보가 표시되는 뷰의 오른쪽에 새 창이 표시됩니다.
브랜치와 연결된 작업을 더블 클릭하거나 브라우저에서 이슈 열기 버튼()을 클릭하면 새 웹 브라우저 창이 열립니다. 사용자가 상태 또는 다른 이슈 필드를 변경하는 경우, VersionOne 확장을 새로 고치면 새 정보가 표시됩니다.
체인지 세트 기반 작업 작업 모드로 작업하도록 Plastic SCM을 구성하려면 사용자가 이전 클라이언트 섹션에서 설명된 바와 같이 VersionOne 확장을 구성하고 Plastic 체인지 세트로 이슈 바인드 옵션을 선택해야 합니다.
워크플로는 다음과 비슷합니다.
Plastic SCM - Windows - 체크인 다이얼로그 및 새 이슈 추가 옵션
Plastic SCM - Linux - 체크인 다이얼로그 및 새 이슈 추가 옵션
Plastic SCM - macOS - 체크인 다이얼로그 및 새 이슈 추가 옵션
Plastic SCM - Windows - 이슈 추가
Plastic SCM - Linux - 이슈 추가
Plastic SCM - macOS - 이슈 추가
체인지 세트가 VersionOne 작업에 연결되면 확장 정보()가 체인지 세트 뷰에 표시됩니다. 또한 사용자는 VersionOne 확장 정보에서 새 작업을 추가하거나 이전 작업을 삭제할 수 있습니다. 또한 특정 체인지 세트에 연결된 각 이슈를 더블 클릭하거나 브라우저에서 이슈 열기 버튼()을 클릭하면 VersionOne을 보여 주는 브라우저가 열립니다. VersionOne에서 사용자가 이슈를 수정할 때마다 VersionOne 확장 정보를 새로 고치면 해당 내용이 Plastic SCM에 표시됩니다.
이 섹션에서는 Plastic SCM과 FogBugz의 통합을 사용하기 위해 따라야 하는 단계를 설명합니다.
이 확장은 FogBugz 버전 7.2 이상과 호환됩니다.
서버 측과 클라이언트 측에서 모두 FogBugz 통합을 구성하는 방법을 알아봅니다.
Plastic SCM FogBugz 확장의 경우 서버 측에서는 변경할 필요가 없습니다.
Windows, Linux, macOS 시스템에서 FogBugz 통합을 구성하는 방법을 살펴보십시오.
다음 단계에 따라 Windows 기기의 Plastic SCM 클라이언트에 FogBugz 확장을 구성합니다.
plastic-global-config 리포지토리를 선택합니다.
Repositories를 선택합니다.
다음 방법 중 하나를 사용하여 Linux 또는 macOS 기기의 Plastic SCM 클라이언트에 FogBugz 확장을 구성할 수 있습니다.
$HOME/.plastic4 아래에 issuetrackers/server_port/repository 구조를 생성합니다. 여기서 repository는 다음 값 중 하나입니다.
allrepos, 즉 이슈 추적기에 연결되는 모든 리포지토리.
fogbugz.conf 예시 구성 파일을 새로 생성된 경로로 복사합니다. plasticscm_install_path/client/extensions/config_samples
/Applications/PlasticSCM.app/Contents/IssueTrackerConfigSamples
그러면 다음과 같은 구조가 됩니다.
fogbugz.conf 파일을 편집합니다.
WorkingMode 매개 변수를 편집하여 TaskOnBranch 또는 TaskOnChangeset 값 중 하나를 할당합니다.
client.conf 파일을 편집하여 다음 키를 추가합니다.
<Extensions>
<Extension AssemblyFile="plasticscm_install_path/client/extensions/fogbugz/fogbugzextension.dll" />
</Extensions>
FogBugz URL: FogBugz 서버가 설치되고 실행되는 URL을 지정합니다.
User name 및 Password: 이 필드에는 유효한 FogBugz 사용자를 입력해야 합니다.
Branch prefix: 브랜치 기반 작업 모드를 사용할 경우 이 Branch prefix를 지정하는 것이 좋습니다(필수는 아님). 이 브랜치 접두어는 Plastic 브랜치를 FogBugz 작업에 바인드하는 데 사용됩니다. Enable checkin log: 이 옵션을 사용하면 FogBugz가 Plastic SCM에서 실행되는 모든 체크인 작업을 기록할 수 있습니다.
기본적으로 구성된 작업 모드는 브랜치 기반 작업 모드로, 각 작업에 대해 새 브랜치가 생성되는 "작업별 브랜치" 패턴에 사용됩니다.
Plastic SCM과 FogBugz 확장을 사용하려면 FogBugz에서 작업을 생성해야 합니다. 일반적으로 프로젝트 매니저가 "새 케이스" 옵션을 클릭하여 이 작업을 수행합니다. 새 작업 데이터를 입력하는 새 다이얼로그 창이 열립니다.
이슈가 생성되면 FogBugz는 이슈에 번호를 할당합니다. 그런 다음 해당 작업을 할당받은 개발자는 관련 작업을 시작합니다. 따라서 아래 이미지에 표시된 것처럼 새 브랜치를 생성합니다(부모 브랜치를 오른쪽 클릭하고 자식 브랜치 생성 옵션을 선택). FogBugz에서 브랜치를 작업에 연결하려면 브랜치 이름이 구성된 브랜치 접두어(정의된 경우) 및 작업 번호(이 경우 이슈 번호 4)와 일치해야 합니다.
이제 사용자가 브랜치 뷰의 확장된 정보()로 이동하고 브랜치를 선택하여 이슈에 대한 정보를 확인할 수 있습니다. 작업 번호, 소유자 등의 FogBugz 확장 정보가 표시되는 뷰의 오른쪽에 새 창이 표시됩니다.
이를 더블 클릭하거나 브라우저에서 이슈 열기 버튼()을 클릭하면 새 웹 브라우저 창이 열립니다. 그러면 FogBugz 작업에 대한 모든 정보가 표시됩니다. 사용자가 상태 또는 다른 이슈 필드를 변경하는 경우, FogBugz 확장의 새로고침 버튼을 클릭하면 새 정보가 표시됩니다.
체인지 세트 기반 작업 작업 모드로 작업하도록 Plastic SCM을 구성하려면 사용자가 이전 클라이언트 섹션에서 설명된 바와 같이 FogBugz 확장을 구성하고 Plastic 체인지 세트로 이슈 바인드 옵션을 선택해야 합니다.
워크플로는 다음과 비슷합니다.
Plastic SCM - Windows - 체크인 다이얼로그 및 새 이슈 추가 옵션
Plastic SCM - Linux - 체크인 다이얼로그 및 새 이슈 추가 옵션
Plastic SCM - macOS - 체크인 다이얼로그 및 새 이슈 추가 옵션
Plastic SCM - Windows - 이슈 추가
Plastic SCM - Linux - 이슈 추가
Plastic SCM - macOS - 이슈 추가
체인지 세트가 FogBugz 이슈 또는 작업에 연결되면 확장 정보()가 체인지 세트 뷰에 표시됩니다. 또한 사용자는 FogBugz 확장 정보에서 새 작업을 추가하거나 이전 작업을 삭제할 수 있습니다. 또한 특정 체인지 세트에 연결된 각 이슈를 더블 클릭하거나 브라우저에서 이슈 열기 버튼()을 클릭하면 FogBugz를 보여 주는 브라우저가 열립니다. FogBugz에서 사용자가 이슈를 수정할 때마다 FogBugz 확장 정보를 새로 고치면 해당 내용이 Plastic에 표시됩니다.
Plastic SCM과 통합된 브랜치 및 체인지 세트와 관련된 이슈에 대한 정보를 표시하는 것 외에도 클라이언트 섹션에서 체크인 로그 활성화 체크박스가 표시된 경우에만 이 확장은 관련된 이슈가 체크인될 때마다 FogBugz에 기록합니다.
따라서 사용자는 "체크인 - 클릭하여 나열" 링크를 클릭하여 각 체크인 작업이 FogBugz 작업에 어떻게 등록되었는지 확인할 수 있습니다.
이 섹션에서는 Plastic SCM과 Rally Software Development의 통합을 사용하기 위해 따라야 하는 단계를 설명합니다.
이 장에서는 서버 측과 클라이언트 측에서 모두 Rally 통합을 구성하는 방법을 알아봅니다.
Rally 확장 기능을 설치하려면 유효한 Rally 계정이 필요합니다. Rally는 웹 기반 서비스로, Rally에 대한 모든 작업이 인터넷을 통해 이루어지므로 서버 측이나 로컬에는 설치할 것이 없습니다.
Windows, Linux, macOS 시스템에서 Rally 통합을 구성하는 방법을 살펴보십시오.
다음 단계에 따라 Windows 기기의 Plastic SCM 클라이언트에 Rally 확장을 구성합니다.
plastic-global-config 리포지토리를 선택합니다.
Repositories를 선택합니다.
다음 방법 중 하나를 사용하여 Linux 또는 macOS 기기의 Plastic SCM 클라이언트에 Rally 확장을 구성할 수 있습니다.
$HOME/.plastic4 아래에 issuetrackers/server_port/repository 구조를 생성합니다. 여기서 repository는 다음 값 중 하나입니다.
allrepos, 즉 이슈 추적기에 연결되는 모든 리포지토리.
rally.conf 예시 구성 파일을 새로 생성된 경로로 복사합니다. plasticscm_install_path/client/extensions/config_samples
/Applications/PlasticSCM.app/Contents/IssueTrackerConfigSamples
그러면 다음과 같은 구조가 됩니다.
rally.conf 파일을 편집합니다.
WorkingMode 매개 변수를 편집하여 TaskOnBranch 또는 TaskOnChangeset 값 중 하나를 할당합니다.
client.conf 파일을 편집하여 다음 키를 추가합니다.
<Extensions>
<Extension AssemblyFile="plasticscm_install_path/client/extensions/rally/rally.dll" />
</Extensions>
Rally URL: Rally 서버가 실행되는 URL을 지정합니다.
User name 및 Password: 이 필드에는 구성된 Rally 서버에 유효한 Rally 사용자를 입력해야 합니다.
Task prefix, Defect prefix, Test case prefix, User story prefix: Plastic SCM에 연결할 수 있는 Rally 객체입니다. 이 작업 모드를 사용하기 위한 첫 번째 단계로, 이전 섹션에 나와 있는 내용을 따라 Plastic SCM Rally 확장에서 이를 설정하거나 이 모드로 적용되는 기본 구성을 그대로 둡니다.
Plastic SCM과 Rally 확장을 사용하려면 Rally에서 객체를 생성해야 합니다.
이 탭에서 "새 결함" 작업을 클릭하여 결함을 생성할 수 있습니다. "작업", "테스트 케이스", "사용자 스토리"와 같은 나머지 Rally 객체도 마찬가지입니다.
"결함 생성" 창에는 새 작업 이름, 우선 순위, 상태 등의 정보가 포함되어야 합니다. 새 결함이 저장되면 Rally는 ID 문자열을 결함에 부여하며, 이는 Plastic 브랜치 생성 시 할당된 개발자가 나중에 해당 작업을 수행하기 위해 사용합니다. 접두어 ID는 객체 유형에 따라 달라집니다. 예를 들어 사용자가 새 작업을 생성하는 경우 ID는 TA4이거나 결함의 경우 DE4가 될 수 있습니다.
확장된 정보 표시 버튼()을 클릭하면 다음 스크린샷에 표시된 것처럼 브랜치 관련 정보가 GUI의 오른쪽에 표시됩니다. 브랜치를 선택하면 Rally 객체에 대한 자세한 정보가 표시됩니다.
이를 더블 클릭하거나 브라우저에서 이슈 열기 버튼()을 클릭하면 관련 브랜치 작업이 나와 있는 웹 브라우저 창이 열립니다. 사용자가 작업을 완료하고 상태 또는 다른 필드를 변경하는 경우 새 값을 보려면 사용자는 Plastic 브랜치 관련 확장된 정보에서 이를 새로 고치면 됩니다.
체인지 세트 기반 작업 작업 모드로 작업하도록 Plastic SCM을 구성하려면 사용자가 이전 클라이언트 섹션에서 설명된 바와 같이 Rally 확장을 구성하고 Plastic 체인지 세트로 이슈 바인드 옵션을 선택해야 합니다.
워크플로는 다음과 비슷합니다.
Plastic SCM - Windows - 체크인 다이얼로그 및 새 이슈 추가 옵션
Plastic SCM - Linux - 체크인 다이얼로그 및 새 이슈 추가 옵션
Plastic SCM - macOS - 체크인 다이얼로그 및 새 이슈 추가 옵션
Plastic SCM - Windows - 이슈 추가
Plastic SCM - Linux - 이슈 추가
Plastic SCM - macOS - 이슈 추가
체인지 세트가 Rally 객체에 연결되면 해당 정보가 체인지 세트 뷰에 표시되고 사용자는 새 링크를 Rally 객체에 추가하거나 기존 링크를 삭제할 수도 있습니다. 또한 각 이슈를 더블 클릭하거나 브라우저에서 이슈 열기 버튼()을 클릭하면 Rally의 관련 객체가 나와 있는 웹 브라우저 창이 열립니다. 이슈 추적 툴에서 사용자가 결함, 작업, 테스트 케이스 또는 사용자 스토리를 수정할 때마다 Rally 확장의 새로고침 버튼을 클릭하면 변경사항이 로드됩니다.
이 섹션에서는 Plastic SCM과 Polarion Software Development의 통합을 사용하기 위해 따라야 하는 단계를 설명합니다.
서버 측과 클라이언트 측에서 모두 Polarion 통합을 구성하는 방법을 살펴보십시오.
Polarion 확장 기능을 설치하려면 다음과 같은 작업을 수행해야 합니다.
client/polarion 폴더의 com.codicesoftware.platform.repository.external.plasticscm 디렉터리를 Polarion 확장 폴더인 [Polarion installation]/polarion/extensions로 복사합니다.
client 폴더를 복사하면 됩니다. 이 경우 cm 실행 파일이 있는 client 폴더에 유효한 client.conf가 있어야 합니다.
Windows, Linux, macOS 시스템에서 Polarion 통합을 구성하는 방법을 알아보시기 바랍니다.
다음 단계에 따라 Windows 기기의 Plastic SCM 클라이언트에 Polarion 확장을 구성합니다.
plastic-global-config 리포지토리를 선택합니다.
Repositories를 선택합니다.
다음 방법 중 하나를 사용하여 Linux 또는 macOS 기기의 Plastic SCM 클라이언트에 Polarion 확장을 구성할 수 있습니다.
$HOME/.plastic4 아래에 issuetrackers/server_port/repository 구조를 생성합니다. 여기서 repository는 다음 값 중 하나입니다.
allrepos, 즉 이슈 추적기에 연결되는 모든 리포지토리.
polarion.conf 예시 구성 파일을 새로 생성된 경로로 복사합니다. plasticscm_install_path/client/extensions/config_samples
/Applications/PlasticSCM.app/Contents/IssueTrackerConfigSamples
그러면 다음과 같은 구조가 됩니다.
polarion.conf 파일을 편집합니다.
WorkingMode 매개 변수를 편집하여 TaskOnBranch 또는 TaskOnChangeset 값 중 하나를 할당합니다.
client.conf 파일을 편집하여 다음 키를 추가합니다.
<Extensions>
<Extension AssemblyFile="plasticscm_install_path/client/extensions/polarion/polarionextension.dll" />
</Extensions>
Polarion Base URL: Polarion 서버가 설치되고 실행되는 URL을 지정합니다.
User name 및 Password: 이 필드에는 유효한 Polarion 사용자를 입력해야 합니다.
Branch prefix: 브랜치 기반 작업 모드를 사용할 경우 이 매개 변수를 지정하는 것이 좋습니다(필수는 아님). 이 브랜치 접두어는 Plastic 브랜치를 Polarion 작업에 바인드하는 데 사용됩니다. Work Item Statuses: 작업에서 모드를 사용하여 새 브랜치를 생성할 때 "대기 중인 작업" 목록에 표시될 작업 항목 유형입니다. 체인지 세트 기반 작업 모드를 사용하여 새 개정을 연결할 때 이러한 값도 검사됩니다. Open Work Item Status: 사용자가 작업에서 모드를 사용하여 새 브랜치를 생성하는 경우 Polarion 작업이 갖게 될 새 상태이며, Mark as open in issue tracker 옵션도 검사합니다.
Repository ID: 이 매개 변수는 Polarion 서버 측에서 구성된 "ID" 필드에 있는 것과 동일합니다.
Default Repository: 이 필드는 선택한 리포지토리가 기본 리포지토리인지 여부를 나타냅니다. 기본 리포지토리를 선택하지 않은 경우 여러 리포지토리를 선택할 수 있습니다.
기본적으로 구성된 작업 모드는 브랜치 기반 작업 모드로, "작업별 브랜치" 패턴과 잘 동작합니다. 이 작업 모드에서는 수행할 각 작업에 대한 새 브랜치가 생성됩니다.
Plastic SCM과 Polarion 확장을 사용하려면 이슈 추적 시스템에서 Polarion 프로젝트와 관련된 새 작업 항목을 생성하여 작업을 생성해야 합니다.
이름, 설명, 우선 순위와 같이 새 작업과 관련된 데이터를 입력하고 "생성" 버튼을 클릭합니다.
Polarion에서 새로 생성된 작업에 번호를 할당하며, 이 번호는 해당 작업을 수행할 때 Plastic 브랜치에 부여되는 것과 동일한 번호입니다.
그런 다음 해당 이슈가 할당된 개발자는 관련 작업을 시작합니다. 그는 Plastic SCM GUI 클라이언트를 사용하여 새 브랜치를 생성합니다. 새 브랜치를 생성하여 Polarion에 연결하는 방법으로 두 가지 옵션이 있습니다.
이 모드에서 사용자는 다음을 수행합니다.
이 내용은 클라이언트 구성 섹션에서 확인할 수 있습니다.
브랜치 뷰에서 확장된 정보 표시 버튼()을 클릭하면 브랜치 관련 정보가 Plastic GUI의 오른쪽 패널에 표시됩니다. 브랜치를 선택하면 Polarion 이슈 정보가 Plastic SCM에 표시됩니다.
작업을 더블 클릭하거나 브라우저에서 이슈 열기 버튼()을 누르면 관련 브랜치 이슈를 보여 주는 새 브라우저 창이 열리고 Polarion 작업에 대한 모든 정보가 표시됩니다.
Polarion에서 사용자가 작업 항목 값을 변경하는 경우, Polarion 확장 패널의 새로고침 버튼을 클릭하면 새 정보가 Plastic에 표시됩니다.
체인지 세트 기반 작업 작업 모드로 작업하도록 Plastic SCM을 구성하려면 사용자가 이전 클라이언트 구성 섹션에서 설명된 바와 같이 Polarion 확장을 구성하고 Plastic 체인지 세트로 이슈 바인드 옵션을 선택해야 합니다.
워크플로는 다음과 비슷합니다.
Plastic SCM - Windows - 체크인 다이얼로그 및 새 이슈 추가 옵션
Plastic SCM - Linux - 체크인 다이얼로그 및 새 이슈 추가 옵션
Plastic SCM - macOS - 체크인 다이얼로그 및 새 이슈 추가 옵션
Plastic SCM - Windows - 이슈 추가
Plastic SCM - Linux - 이슈 추가
Plastic SCM - macOS - 이슈 추가
다음 예에서 두 Polarion 작업 항목은 체크인될 변경사항과 연결됩니다.
Polarion 확장은 연결할 작업 항목의 상태를 검사합니다. 클라이언트 구성의 작업 항목 상태 필드에 상태가 정의된 Polarion 작업 항목만 연결할 수 있습니다. 구성된 작업 항목 상태가 초안과 공개임을 이전에 확인한 바 있습니다. 따라서 다른 상태는 허용되지 않습니다.
Polarion에서 체인지 세트가 작업 항목에 연결되면 이 정보를 Plastic SCM 체인지 세트 뷰에 표시할 수 있습니다. 확장된 정보 패널()이 표시되면 체인지 세트를 클릭하여 연결된 Polarion 작업 항목을 표시합니다.
또한 사용자는 Polarion 확장 정보에서 새 작업을 추가하거나 이전 작업을 삭제할 수 있습니다. 그 외에도 특정 체인지 세트에 연결된 각 이슈를 더블 클릭하면 선택한 Polarion 작업 항목을 보여 주는 새 웹 브라우저 창이 열립니다. 작업 추적 툴에서 사용자가 이슈를 수정할 때마다 Polarion 확장 창에서 새로고침 버튼을 누르면 Plastic GUI에서 새 데이터가 업데이트됩니다.
Plastic SCM Polarion 통합은 연결된 개정이 체인지 세트 ID(정수) 대신 체인지 세트 GUID를 사용하는 분산형 시나리오를 지원합니다.
하지만 체인지 세트 정보(예: 체인지 세트 코멘트)는 Polarion에서 구성된 Plastic SCM 서버로 체인지 세트가 복제될 때까지 제공되지 않습니다.
앞서 확인한 것처럼 모든 Polarion 작업 항목 정보는 관련 브랜치 또는 체인지 세트를 통해 Plastic에 가져올 수 있습니다. 그리고 Plastic에서 생성된 개정과 관련된 모든 정보를 Polarion 측에 가져올 수도 있습니다. Polarion 통합은 다음과 같은 방법으로 수정된 항목에 대한 기록을 유지합니다. 변경사항이 Plastic에서 체크인되고 통합이 활성화되는 경우, Polarion에서는 브랜치 기반 작업 모드
또는 체인지 세트 기반 작업 중 하나를 사용하여 "연결된 개정" 섹션에 영향을 받는 항목을 표시합니다.
Plastic 개정이 Polarion에 올바르게 연결되면 아이콘 개정에 녹색 총알이 포함된 모습을 확인할 수 있습니다. 
Plastic SCM과 codeBeamer의 통합을 사용하려면 이 섹션의 단계를 따르십시오.
서버 측과 클라이언트 측에서 모두 codeBeamer 통합을 구성하는 방법을 알아봅니다.
Plastic SCM codeBeamer 확장 구성의 경우 서버 측에서는 변경할 필요가 없습니다.
단, codeBeamer 구성에 웹훅 비밀 토큰을 추가하려는 경우 다음 단계를 따르십시오.
"scc" 노드가 없다면 추가합니다.
"scc" 노드의 json에 "plasticscm" 노드가 없다면 추가합니다.
"plasticscm" 노드에서 "secretToken" : "<secret_token_of_the_webhook>"을 추가합니다.
Windows, Linux, macOS 시스템에서 codeBeamer 통합을 구성하는 방법을 알아보시기 바랍니다.
다음 단계에 따라 Windows 기기의 Plastic SCM 클라이언트에 codeBeamer 확장을 구성합니다.
plastic-global-config 리포지토리를 선택합니다.
Repositories를 선택합니다.
다음 방법 중 하나를 사용하여 Linux 또는 macOS 기기의 Plastic SCM 클라이언트에 codeBeamer 확장을 구성할 수 있습니다.
$HOME/.plastic4 아래에 issuetrackers/server_port/repository 구조를 생성합니다. 여기서 repository는 다음 값 중 하나입니다.
allrepos, 즉 이슈 추적기에 연결되는 모든 리포지토리.
codebeamer.conf 예시 구성 파일을 새로 생성된 경로로 복사합니다. plasticscm_install_path/client/extensions/config_samples
/Applications/PlasticSCM.app/Contents/IssueTrackerConfigSamples
그러면 다음과 같은 구조가 됩니다.
codebeamer.conf 파일을 편집합니다.
WorkingMode 매개 변수를 편집하여 TaskOnBranch 또는 TaskOnChangeset 값 중 하나를 할당합니다.
client.conf 파일을 편집하여 다음 키를 추가합니다.
<Extensions>
<Extension AssemblyFile="plasticscm_install_path/client/extensions/codebeamer/codebeamerextension.dll" />
</Extensions>
codeBeamer URL: codeBeamer 서버가 설치되고 실행되는 URL을 지정합니다.
User name 및 Password: 이 필드에는 유효한 codeBeamer 사용자를 입력해야 합니다.
Branch prefix: 브랜치 기반 작업 모드를 사용할 경우 이 매개 변수를 지정하는 것이 좋습니다(필수는 아님). 이 브랜치 접두어는 Plastic 브랜치를 codeBeamer 작업에 바인드하는 데 사용됩니다. Enable SCM log: codeBeamer 버전이 외부 SCM 통합을 지원하는 경우 이 체크박스를 활성화합니다.
Secret token: codeBeamer 서버에 비밀 토큰 값이 구성되어 있는 경우 이를 입력합니다.
기본적으로 구성된 작업 모드는 브랜치 기반 작업 모드로, "작업별 브랜치" 패턴과 잘 동작합니다. 이 작업 모드에서는 수행할 각 작업에 대한 새 브랜치가 생성됩니다.
Plastic SCM과 codeBeamer 확장을 사용하려면 codeBeamer에서 작업을 생성해야 합니다.
새 작업이 저장되면 codeBeamer가 이 작업에 ID 번호를 부여합니다. 해당 작업을 수행하기 위해 Plastic SCM 브랜치 생성 시 할당된 개발자가 이 번호를 사용합니다.
그런 다음 해당 작업을 할당받은 개발자는 관련 작업을 시작합니다. Plastic SCM GUI 클라이언트를 사용하여 새 브랜치를 생성할 것입니다. 새 브랜치를 생성하여 codeBeamer에 연결하려면 두 가지 옵션을 사용할 수 있습니다.
Plastic SCM - Windows - "수동으로" 새 브랜치 생성
Plastic SCM - Linux - "수동으로" 새 브랜치 생성
Plastic SCM - macOS - "수동으로" 새 브랜치 생성
Plastic SCM - Windows - "작업에서" 새 브랜치 생성
Plastic SCM - Linux - "작업에서" 새 브랜치 생성
Plastic SCM - macOS - "작업에서" 새 브랜치 생성
브랜치 뷰에서 확장된 정보 표시 버튼()을 클릭하면 브랜치 관련 정보가 Plastic GUI의 오른쪽 패널에 표시됩니다. Plastic 브랜치를 선택하면 codeBeamer 작업 정보가 표시됩니다.
작업을 더블 클릭하거나 브라우저에서 이슈 열기 버튼()을 누르면 관련 codeBeamer 작업에 대한 모든 정보를 보여 주는 새 브라우저 창이 열립니다. 사용자가 작업 필드를 변경하는 경우, codeBeamer 확장 패널의 새로고침 버튼을 클릭하면 새 정보가 표시됩니다.
체인지 세트 기반 작업 작업 모드로 작업하도록 Plastic SCM을 구성하려면 사용자가 이전 클라이언트 섹션에서 설명된 바와 같이 codeBeamer 확장을 구성할 때 Plastic 체인지 세트로 이슈 바인드 옵션을 선택해야 합니다.
워크플로는 다음과 비슷합니다.
Plastic SCM - Windows - 체크인 다이얼로그 및 새 이슈 추가 옵션
Plastic SCM - Linux - 체크인 다이얼로그 및 새 이슈 추가 옵션
Plastic SCM - macOS - 체크인 다이얼로그 및 새 이슈 추가 옵션
Plastic SCM - Windows - 이슈 추가
Plastic SCM - Linux - 이슈 추가
Plastic SCM - macOS - 이슈 추가
체인지 세트가 codeBeamer 작업에 연결되면 이 정보를 Plastic SCM 체인지 세트 뷰에 표시할 수 있습니다. 확장된 정보 패널이 표시되면() 체인지 세트를 클릭하는 경우 연결된 codeBeamer 작업이 Plastic에 표시됩니다.
또한 사용자는 codeBeamer 확장 창에서 새 작업을 추가하거나 이전 작업을 삭제할 수 있습니다. 그 외에도 특정 체인지 세트에 연결된 각 작업을 더블 클릭하거나 브라우저에서 이슈 열기 버튼()을 클릭하면 새 웹 브라우저 창이 열리고 선택한 codeBeamer 작업이 표시됩니다. codeBeamer에서 사용자가 작업을 수정할 때마다 codeBeamer 확장 창에서 새로고침 버튼을 누르면 Plastic GUI에서 새 데이터가 업데이트됩니다.
Plastic SCM과 통합된 브랜치 및 체인지 세트와 관련된 이슈에 대한 정보를 표시하는 것 외에도 이 확장은 이슈 연결이 체크인될 때마다 codeBeamer에 기록합니다.
Enable SCM log 매개 변수를 FALSE로 설정하십시오.
이러한 방법으로 각 체크인 작업이 codeBeamer에 어떻게 등록되는지 확인할 수 있습니다.
클라이언트가 모두 동일한 기본값으로 설정되도록 서버에서 전역 구성을 설정할 수 있습니다. 이렇게 하면 연결 문자열과 같은 기본 전역 매개 변수를 설정하고 사용자가 자신의 특정 사용자 증명을 지정할 때 유용합니다.
서버 측에서 전역 구성이 생성되면, Plastic GUI를 시작할 때 해당 서버 구성이 클라이언트 측에 다운로드됩니다.
서버에서 전역 구성을 설정하려면 plastic-global-config라는 리포지토리를 생성합니다. 이 리포지토리는 리포지토리에 적용되고 Plastic 사용자가 사용하는 이슈 추적기 확장 프로그램을 위한 구성 파일이 포함된 적절하게 정의된 구조를 가지고 있습니다.
plastic-global-config의 구조는 다음과 같습니다.
/repname/issuetrackers/extension_configuration_file.conf. /allrepos/issuetrackers/extension_configuration_file.conf. /myrepo-mysubrepo/issuetrackers/extension_configuration_file.conf
plastic-global-config 리포지토리는 2개 이상의 이슈 추적 시스템으로 구성될 수 있습니다. Plastic 클라이언트는 사용자가 작업할 리포지토리의 특정 구성을 먼저 로드합니다. 특정 구성이 없는 경우 allrepos 구성이 로드됩니다.
전역 확장 구성을 설정하기 위한 첫 번째 단계는 서버에 plastic-global-config 리포지토리를 생성하는 것입니다(이전에 전역 파일 구성을 설정할 때 생성되어 아직 없는 경우).
그런 다음, 이 리포지토리에는 이전에 확인한 것처럼 필요한 구조가 있어야 합니다. 다음 예시에서 vb44 리포지토리는 Bugzilla로 연결되고 나머지 리포지토리는 Jira로 연결됩니다.
Plastic SCM GUI - Windows - plastic-global-config 예시
Plastic SCM GUI - Linux - plastic-global-config 예시
Plastic SCM GUI - macOS - plastic-global-config 예시
plasticscm_install_path/client/extensions/config_samples 폴더에 있습니다. 필요한 매개 변수를 포함하고 업데이트해야 합니다.
클라이언트 GUI 시작 시 각 서버 구성은 사용자 로컬 디렉터리(plastic4 디렉터리(Linux/Mac 시스템의 경우 $HOME/.plastic4 아래, Windows의 경우 C:\Users\사용자\AppData\Local\plastic4 아래))에 자동으로 생성될 숨겨진 워크스페이스에 다운로드됩니다. 예를 들면 C:\Users\user\AppData\Local\plastic4\globalconfig\server_port입니다.
필요한 경우 모든 클라이언트에서 사용하는 자격 증명으로 이슈 추적기 구성을 커스터마이즈할 수 있습니다. 이러한 방법으로 사용자가 Plastic SCM 클라이언트의 기본 설정 다이얼로그에서 이슈 추적 탭을 열면 연결된 이슈 추적기의 공통 값과 전역 값이 자동으로 로드되며, 사용자는 이슈 추적 시스템에 올바르게 로그인할 수 있는 자격 증명 정보만 입력해야 합니다.
이러한 사용자 자격 증명은 사용자 로컬 디렉터리에 저장됩니다(plastic4 디렉터리(Linux/Mac 시스템의 경우 $HOME/.plastic4 아래, Windows의 경우 C:\Users\사용자\AppData\Local\plastic4 아래)). 예: C:\Users\사용자\AppData\Local\plastic4\issuetrackers\server_port\repname\extension_configuration_file.conf
Plastic SCM에는 가장 많이 사용되는 이슈 추적 및 프로젝트 관리 시스템에 연결할 때 사용할 수 있는 "기본" 이슈 추적기 통합 확장 프로그램이 포함됩니다.
"기본" 확장 프로그램을 사용하면 Plastic SCM에서 브랜치에 연결된 작업에 관한 정보를 표시하거나(권장) 브랜치 탐색기나 체인지 세트 뷰 또는 브랜치 뷰의 체인지 세트에 연결된 작업에 관한 정보를 표시할 수 있습니다. 따라서 작업 패턴마다 브랜치를 구현하거나 개별 체인지 세트를 작업에 연결하는 경우 이슈 추적기에 있는 관련 정보를 즉시 사용할 수 있습니다.
커스텀 "확장 프로그램"을 개발하는 방법을 만든 이유는 시장에 있는 모든 ALM, 이슈 추적기, 빌드 시스템과의 통합이 불가능할 것 같기 때문입니다. 따라서, 일반적인 이슈 추적기 연결 인터페이스를 설계했으므로 Plastic SCM의 커스텀 확장 프로그램을 직접 작성할 수 있습니다.
Plastic SCM에 커스텀 확장 프로그램을 작성하려는 경우, 기기에 Visual Studio와 Plastic SCM 클라이언트를 설치해야 합니다. 이슈 추적기 확장 프로그램을 제작하는 데 필요한 라이브러리는 issuetrackerinterface.dll 단 하나입니다. 로깅 기능을 추가하려면 Plastic SCM에서 사용하는 log4net.dll을 활용할 수 있습니다.
새 확장을 생성하려면 먼저 Visual Studio에서 Class Library 프로젝트를 생성하고 issuetrackerinterface.dll 레퍼런스를 추가해야 합니다(원하는 경우 log4net.dll 추가).
Visual Studio에서 Class Library뿐만 아니라 두 가지 다른 인터페이스를 구현해야 합니다.
IPlasticIssueTrackerExtension: Plastic SCM을 위한 이슈 추적기 연결 기능을 정의합니다.IPlasticIssueTrackerExtensionFactory: 이슈 추적기 확장 프로그램 구성 및 생성을 관리합니다.
Class Library와 파일이 설치되면 이제 Plastic SCM을 사용할 수 있습니다. 우선 SampleExtension이라는 새 클래스를 추가합니다. 또한 클래스를 Codice.Client.IssueTracker.SampleExtension에 배치하도록 네임스페이스를 변경합니다.
namespace Codice.Client.IssueTracker.SampleExtension
{
public class SampleExtension : IPlasticIssueTrackerExtension
{
}
}
우선 확장 구성을 저장해야 합니다. 클래스 구성자를 통해 이 작업을 처리합니다. 오직 공장에서만 이러한 종류의 객체를 생성하는 방법을 알아야 하므로, 가시성을 internal로 설정합니다.
public class SampleExtension : IPlasticIssueTrackerExtension
{
IssueTrackerConfiguration mConfig;
// If you want logging, this is the way to declare it
// Don't forget to set log4net.dll as a reference!
static readonly ILog mLog = LogManager.GetLogger("sampleextension");
Internal SampleExtension(IssueTrackerConfiguration config)
{
mConfig = config;
mLog.Info("Sample issue tracker is initialized");
}
}
이슈 추적기 확장 프로그램 클래스를 생성하는 방법을 정의했으므로 공장을 구축할 수 있습니다. 이와 관련하여 IPlasticIssueTrackerExtension 인터페이스를 구현하는 새 SampleExtensionFactory 클래스를 추가합니다. Visual Studio 리팩터 옵션을 사용하여 필요한 모든 메서드를 추가합니다(인터페이스 레퍼런스를 오른쪽 클릭하고 리팩터 > 인터페이스 구현 선택). 그러면 인터페이스 메서드마다 스텁이 추가됩니다. 이는 다음과 같이 시작합니다.
namespace Codice.Client.IssueTracker.SampleExtension
{
public class SampleExtensionFactory : IPlasticIssueTrackerExtensionFactory
{
public IssueTrackerConfiguration GetConfiguration(
IssueTrackerConfiguration storedConfiguration)
{
throw new NotImplementedException();
}
public IPlasticIssueTrackerExtension GetIssueTrackerExtension(
IssueTrackerConfiguration configuration)
{
throw new NotImplementedException();
}
public string GetIssueTrackerName()
{
throw new NotImplementedException();
}
}
}
마지막 두 메서드는 구현이 매우 쉽습니다.
public IPlasticIssueTrackerExtension GetIssueTrackerExtension(
IssueTrackerConfiguration configuration)
{
return new SampleExtension(configuration);
}
public string GetIssueTrackerName()
{
return "Sample Issue Tracker";
}
이는 작동 중인 이슈 트래커 확장을 유효한 구성과 이슈 추적기 이름에서 각각 반환합니다. 하지만 첫 번째는 이슈 추적기 구성을 수신하여 유효한 구성을 반환하므로 조금 복잡합니다. 그런 다음 필요한 매개 변수와 그 기본값을 정의해야 합니다.
IssueTrackerConfiguration 클래스는 매우 간단하며, 이는 열거형 ExtensionWorkingMode 필드와 IssueTrackerConfigurationParameter 목록을 저장합니다.
작업 모드는 두 값을 허용합니다.
이 구성 매개 변수는 Plastic SCM 기본 설정 다이얼로그의 이슈 추적기 탭에 나열됩니다. 자세한 내용은 아래의 확장 구성 섹션을 참조하십시오.
두 가지(현재 사용자 ID 및 Plastic SCM 브랜치 접두어)만 정의합니다. 첫 번째는 현재 대기 중인 작업 결과에 영향을 미치는 반면, 두 번째는 브랜치가 이슈 추적기 작업에 연결되는 경우 추측 시 예상할 브랜치 접두어를 Plastic에 전달합니다.
기본적으로 각 매개 변수에는 4개의 속성(name, value, type, IsGlobal)이 있습니다. 첫 두 가지는 단지 두 개의 문자열 클래스 속성으로, 자신에 대한 설명이 포함되어 있습니다. 이 매개 변수 유형은 열거형 IssueTrackerConfigurationParameterType에 의해 정의됩니다. 이는 매개 변수에 포함된 사항을 설명합니다.
호스트, 사용자, 비밀번호를 제외하고 매개 변수의 숫자를 동일한 유형으로 정의할 수 있습니다. 확장 모드가 TaskOnChangeset로 전환되면 구성 패널은 모든 BranchPrefix 항목을 비활성화합니다.
마지막으로, GetConfiguration 메서드의 모습은 다음과 같습니다.
public IssueTrackerConfiguration GetConfiguration(
IssueTrackerConfiguration storedConfiguration)
{
List<IssueTrackerConfigurationParameter> parameters
= new List<IssueTrackerConfigurationParameter>();
ExtensionWorkingMode workingMode = GetWorkingMode(storedConfiguration);
string user = GetValidParameterValue(
storedConfiguration, SampleExtension.USER_KEY, "1");
string prefix = GetValidParameterValue(
storedConfiguration, SampleExtension.BRANCH_PREFIX_KEY, "sample");
IssueTrackerConfigurationParameter userIdParam =
new IssueTrackerConfigurationParameter()
{
Name = SampleExtension.USER_KEY,
Value = GetValidParameterValue(
storedConfiguration, SampleExtension.USER_KEY, "1"),
Type = IssueTrackerConfigurationParameterType.User,
IsGlobal = false
};
IssueTrackerConfigurationParameter branchPrefixParam =
new IssueTrackerConfigurationParameter()
{
Name = SampleExtension.BRANCH_PREFIX_KEY,
Value = GetValidParameterValue(
storedConfiguration, SampleExtension.BRANCH_PREFIX_KEY, "scm"),
Type = IssueTrackerConfigurationParameterType.BranchPrefix,
IsGlobal = true
};
parameters.Add(userIdParam);
parameters.Add(branchPrefixParam);
return new IssueTrackerConfiguration(workingMode, parameters);
}
ExtensionWorkingMode GetWorkingMode(IssueTrackerConfiguration config)
{
if (config == null)
return ExtensionWorkingMode.TaskOnBranch;
if (config.WorkingMode == ExtensionWorkingMode.None)
return ExtensionWorkingMode.TaskOnBranch;
return config.WorkingMode;
}
string GetValidParameterValue(
IssueTrackerConfiguration config, string paramName, string defaultValue)
{
string configValue = (config != null) ? config.GetValue(paramName) : null;
if (string.IsNullOrEmpty(configValue))
return defaultValue;
return configValue;
}
공장을 완성했습니다. Extension 클래스로 돌아가겠습니다.
다음 단계로, 모든 인터페이스 메서드를 구현합니다. Visual Studio 리팩터를 사용하여 모든 인터페이스 메서드를 추가합니다.
public class SampleExtension : IPlasticIssueTrackerExtension
{
public void Connect()
{
throw new NotImplementedException();
}
public void Disconnect()
{
throw new NotImplementedException();
}
public string GetExtensionName()
{
throw new NotImplementedException();
}
public List<PlasticTask> GetPendingTasks(string assignee)
{
throw new NotImplementedException();
}
public List<PlasticTask> GetPendingTasks()
{
throw new NotImplementedException();
}
public PlasticTask GetTaskForBranch(string fullBranchName)
{
throw new NotImplementedException();
}
public Dictionary<string, PlasticTask> GetTasksForBranches(List<string> fullBranchNames)
{
throw new NotImplementedException();
}
public List<PlasticTask> LoadTasks(List<string> taskIds)
{
throw new NotImplementedException();
}
public void LogCheckinResult(PlasticChangeset changeset, List<PlasticTask> tasks)
{
throw new NotImplementedException();
}
public void MarkTaskAsOpen(string taskId, string assignee)
{
throw new NotImplementedException();
}
public void OpenTaskExternally(string taskId)
{
throw new NotImplementedException();
}
public bool TestConnection(IssueTrackerConfiguration configuration)
{
throw new NotImplementedException();
}
public void UpdateLinkedTasksToChangeset(PlasticChangeset changeset, List<string> tasks)
{
throw new NotImplementedException();
}
}
물론 모든 메서드를 구현할 필요는 없습니다. 필요하지 않거나 제공하지 않으려는 기능이 있다면 메서드 본문을 비워 두거나 기본값을 반환하면 됩니다. 반환 유형이 컬렉션 유형인 경우, null 객체가 아닌 빈 컬렉션을 반환하는 것이 좋습니다.
다음은 각 메서드에 대한 간략한 설명입니다.
ConnectDisconnectConnect와는 반대로, 여기에는 대상 이슈 추적기(세션 등)에 연결하는 데 필요한 리소스를 해제하는 코드가 포함됩니다.GetExtensionNameGetPendingTasksGetTaskForBranchGetTasksForBranchesLoadTasksLogCheckinResultMarkTaskAsOpenOpenTaskExternallyTestConnectionUpdateLinkedTasksToChangeset이러한 메서드를 설명하기 위해 몇 가지 샘플 구현을 살펴보겠습니다. 작업 내용은 https://jsonplaceholder.typicode.com의 lorem ipsum 웹 서비스에서 가져옵니다.
이건 정말 간단합니다. Plastic 뷰에 표시할 이름을 반환하기만 하면 됩니다.
public string GetExtensionName()
{
return "My awesome extension";
}
이슈 추적기 확장 프로그램이 TaskOnBranch 모드에서 작동하도록 구성된 경우, 이 메서드는 가져온 브랜치를 브랜치 탐색기가 연결된 작업에 매핑하는 데 사용됩니다. 또한 코드가 너무 복잡해지지 않도록 이 기능을 여러 메서드로 나누어 가독성을 높였습니다.
public Dictionary<string, PlasticTask> GetTasksForBranches(
List<string> fullBranchNames)
{
Dictionary<string, PlasticTask> result =
new Dictionary<string, PlasticTask>();
foreach(string fullBranchName in fullBranchNames)
{
string taskId = GetTaskIdFromBranchName(
GetBranchName(fullBranchName));
result.Add(fullBranchName, LoadSingleTask(taskId));
}
return result;
}
string GetBranchName(string fullBranchName)
{
int lastSeparatorIndex = fullBranchName.LastIndexOf('/');
if (lastSeparatorIndex < 0 )
return fullBranchName;
if (lastSeparatorIndex == fullBranchName.Length - 1)
return string.Empty;
return fullBranchName.Substring(lastSeparatorIndex + 1);
}
string GetTaskIdFromBranchName(string branchName)
{
string prefix = mConfig.GetValue(BRANCH_PREFIX_KEY);
if (string.IsNullOrEmpty(prefix))
return branchName;
if (!branchName.StartsWith(branchName) || branchName == prefix)
return string.Empty;
return branchName.Substring(prefix.Length);
}
const string POST_URL = "https://jsonplaceholder.typicode.com/posts/{0}";
PlasticTask LoadSingleTask(string taskId)
{
if (string.IsNullOrEmpty(taskId))
return null;
string uri = string.Format(POST_URL, taskId);
string resultJson = PerformJsonRequest(uri);
return BuildTaskFromJson(
JsonConvert.DeserializeObject<MyServiceData>(resultJson));
}
string PerformJsonRequest(string targetUri)
{
HttpWebRequest req = (HttpWebRequest)WebRequest.Create(targetUri);
try
{
using (HttpWebResponse resp = (HttpWebResponse)req.GetResponse())
using (StreamReader reader = new StreamReader(resp.GetResponseStream()))
{
return reader.ReadToEnd();
}
}
catch(Exception e)
{
mLog.ErrorFormat(
"Unable to perform request on URI {0}: {1}", targetUri, e.Message);
mLog.DebugFormat(
"Stack trace:{0}{1}", Environment.NewLine, e.StackTrace);
return string.Empty;
}
}
PlasticTask BuildTaskFromJson(MyServiceData jsonData)
{
if (jsonData == null)
return null;
return new PlasticTask()
{
Id = jsonData.Id.ToString(),
Owner = jsonData.UserId.ToString(),
Title = jsonData.Title,
Description = jsonData.Body,
Status = "working"
};
}
이 메서드는 전체 브랜치 이름(즉, 이 이름에 전체 구조가 포함됨)을 가져옵니다. 이들 각각에 대해 이 메서드는 작업 ID를 추출하고 jsonplaceholder 서비스에 대해 쿼리를 수행합니다.
JsonPlaceholder는 REST 서비스에 상응하는 "lorem ipsum" 생성자입니다. 숫자 값을 전달할 수 있으며, 그러면 일부 샘플 필드와 함께 JSON 객체가 반환됩니다. 숫자 없이 URL을 쿼리하면 객체 목록이 반환됩니다. https://jsonplaceholder.typicode.com에서 자세한 내용을 확인할 수 있습니다.
JSON 응답을 받으면 주로 사용하는 JSON 파서를 사용하여 유효한 객체 인스턴스로 이를 역직렬화할 수 있습니다. 이전 예에서는 Newtonsoft.Json을 사용했습니다.
마지막 단계로 PlasticTask 인스턴스를 빌드하고 REST 서비스에서 반환된 값을 사용하여 필드를 설정합니다. 모든 브랜치 이름이 처리된 경우 이 메서드는 매핑을 Dictionary<string, PlasticTask> 클래스로 반환합니다.
OpenTask 메서드는 정보의 원래 소스에 액세스해야 하는 경우에 사용됩니다. 예를 들어, 필요한 정보가 포함된 웹사이트 또는 타사 애플리케이션이 있을 경우, OpenTask Plastic 이슈 추적기 확장 프로그램에서 메서드를 사용해 이 데이터를 표시할 수 있습니다.
public void OpenTaskExternally(string taskId)
{
Process.Start(string.Format(
"https://www.google.es/search?q={0}", taskId));
}
샘플 구현은 매우 간단합니다. URI를 빌드하여 Google에서 작업 번호를 검색하고 System.Diagnostics.Process 클래스를 사용하여 기본 브라우저로 엽니다.
OpenTask 메서드는 Plastic SCM과 이슈 추적기 간에 긴밀한 통합을 구축해야 하는 경우에 유용합니다.
이전 GetTasksForBranches 코드 샘플을 참조하여 Plastic SCM 브랜치 뷰에서 sample로 시작하는 브랜치를 선택하면 오른쪽 패널에 세부사항이 표시됩니다.
위에서 확인할 수 있듯 오른쪽 패널에는 GetTasksForBranches 메서드에서 가져온 PlasticTask 프로퍼티 정보가 표시됩니다.
TaskOnChangeset 작업 모드를 사용하도록 확장을 구성하면 오른쪽 패널에 세 개의 버튼이 표시됩니다.
첫 번째 버튼을 누르면 앞서 OpenTask 메서드에서 본 것처럼 브라우저에서 작업 정보를 엽니다.
두 번째 버튼을 누르면 선택한 체인지 세트로 작업을 연결합니다. 버튼을 클릭하면 연결할 작업을 선택할 수 있는 다이얼로그가 표시됩니다.
이 다이얼로그에 있는 이슈 열기 버튼은 앞서 설명한 버튼과 같습니다. 주어진 체인지 세트에 이슈를 원하는 만큼 연결할 수 있습니다.
세 번째 버튼을 누르면 현재 선택된 체인지 세트에 연결된 선택된 이슈를 제거합니다.
TaskOnBranch 모드는 브랜치 이름과 접두어를 사용하여 자동으로 이슈를 브랜치에 연결하는 자동화된 메커니즘인 반면, TaskOnChangeset 모드를 사용하면 이슈 정보를 개별 체인지 세트에 수동으로 연결할 수 있습니다. 앞서 본 체인지 세트 뷰의 작업 버튼 외에도 정보 체크인 다이얼로그를 사용하여 체크인 시 연결을 추가할 수 있습니다.
이슈 추적기의 최신 주요 기능은 주어진 이슈에서 새 브랜치를 생성하는 것입니다. 이슈 추적기 확장 프로그램이 적절히 구성될 때마다 브랜치 생성 다이얼로그는 작업에서 모드라는 새로운 컨트롤 세트를 자동으로 표시합니다.
GetPendingTasks 메서드에서 반환된 결과로 채워진 대기 중인 작업 목록을 주로 제어합니다. 기본적으로 현재 사용자에게 할당된 작업(구성 패널에서 설정)만 표시됩니다. 모든 사용자의 대기 중인 작업 표시 제어를 체크하면 체크박스 제목에 표시된 대로 이 제약을 재정의합니다. 브랜치 이름과 코멘트는 자동으로 설정되며, 코멘트의 경우 수정할 수 있습니다.
마지막으로 이슈 추적기에 공개로 표시를 체크하면 브랜치를 성공적으로 생성한 후 MarkTaskAsOpen 메서드가 실행됩니다. 선택한 이슈의 상태를 공개, 진행 중 또는 현재 이슈 추적기에 해당하는 상태로 설정해야 합니다.
클래스 라이브러리를 쓸 때마다 가장 쉽게 코드를 디버그할 수 있는 방법이 무엇인지 의문이 생깁니다. Plastic SCM 확장의 경우 해결책은 명확합니다. 빌드 섹션에서 클래스 라이브러리 속성을 수정하여 .dll 및 .pdb 출력 파일을 바로 Plastic SCM 클라이언트 디렉터리로 배포하면 됩니다.
출력 경로를 설정한 후, Plastic SCM 클라이언트를 실행하고 자동으로 디버거를 결과 plastic.exe 프로세스에 연결하도록 Visual Studio를 구성할 수도 있습니다. 그러면 Plastic이 커스텀 확장 코드와 상호 작용할 때 설정한 중단점이 자동으로 트리거됩니다.
Program Files 아래에 있는 Plastic SCM 클라이언트 디렉터리 내에 컴파일된 파일을 배치할 수 있으려면 그에 따른 적절한 권한이 있어야 합니다.
Plastic에서 커스텀 확장을 확인하려면 Plastic SCM 클라이언트 폴더 내 customextensions.conf 파일을 편집해야 합니다.
# Each line defines a Plastic SCM extension with a name and a relative dll # path from client installation directory # i.e: # My Custom Extension=extensions/mycustomextension/mycustomextension.dll Sample Extension=SampleExtension.dll
이 구성 단계가 끝나면 기본 설정 다이얼로그를 열고 이슈 추적 탭을 열 수 있습니다. 해당 탭의 드롭다운 목록에서 확장 목록을 볼 수 있습니다. 선택하면 확장 구성에 필요한 컨트롤이 기본 패널에 표시됩니다.
적용 또는 확인 버튼을 클릭하면 Plastic에서 새로운 확장을 사용할 수 있습니다.
커스텀 이슈 추적기 확장 프로그램을 사용하면 모든 이슈 추적기를 Plastic SCM과 통합할 수 있습니다. 기업 인트라넷, 사내에서 개발된 이슈 추적 시스템 등 무궁무진한 가능성을 가집니다.
자체 시스템과 연결하기 위한 자체 코드를 개발할 수 있고, 간단히 Plastic SCM 클라이언트와 통합할 수 있는 Plastic SCM은 SCM 환경을 커스터마이즈할 수 있는 뛰어난 기회를 제공합니다.
해당 기능이 마음에 들어 이 샘플 확장의 전체 소스를 얻고자 하는 경우 GitHub 리포지토리를 확인하면 됩니다.
Use LDAP credentials if available, Use default proxy credentials, Issue types 등 새로운 Jira 확장 매개 변수를 구성할 수 있습니다.Pending status list - 이제, "대기 중"으로 간주되는 Axosoft 상태 목록을 구성할 수 있습니다.Default Repository 매개 변수를 구성하십시오.Custom Field ID 매개 변수는 선택사항입니다.Issue query limit - 이제 브랜치 생성 다이얼로그에서 반환된 결과의 최대 개수를 구성할 수 있습니다.Resolved issue states - 이제, '해결됨'으로 간주되는 상태 이름의 목록을 정의할 수 있습니다.