서비스 데스크
Tier: Free, Premium, Ultimate
Offering: GitLab.com, Self-managed
Service Desk를 사용하면 고객이
버그 보고서, 기능 요청 또는 일반 피드백을 이메일로 보낼 수 있습니다.
Service Desk는 고유한 이메일 주소를 제공하므로 고객은 GitLab 계정을 가질 필요가 없습니다.
Service Desk 이메일은 귀하의 GitLab 프로젝트에서 새로운 이슈로 생성됩니다.
귀하의 팀은 프로젝트에서 직접 응답할 수 있으며, 고객은 이메일을 통해서만 스레드와 상호작용합니다.
비디오 개요는 GitLab 서비스 데스크 소개 (GitLab 16.7)를 참조하세요.
서비스 데스크 워크플로우
예를 들어, iOS 또는 Android용 게임을 개발한다고 가정해 봅시다.
코드베이스는 귀하의 GitLab 인스턴스에 호스팅되며, GitLab CI/CD를 사용하여
빌드하고 배포됩니다.
다음은 귀하를 위한 Service Desk의 작동 방식입니다:
- 귀하는 지불 고객에게 프로젝트 특정 이메일 주소를 제공하여 고객이 애플리케이션에서 직접
이메일을 보낼 수 있도록 합니다. - 그들이 보내는 각 이메일은 해당 프로젝트에 이슈를 생성합니다.
- 귀하의 팀원은 서비스 데스크 이슈 트래커로 이동하여 새로운 지원
요청을 보고 관련 이슈 내에서 응답할 수 있습니다. - 귀하의 팀은 고객과 소통하여 요청을 이해합니다.
- 귀하의 팀은 고객의 문제를 해결하기 위해 코드를 구현하는 작업을 시작합니다.
- 귀하의 팀이 구현을 완료하면 병합 요청이 병합되고 이슈가
자동으로 닫힙니다.
동시에:
- 고객은 귀하의 GitLab 인스턴스에 접근할 필요 없이
이메일을 통해 팀과 완전히 상호작용합니다. - 귀하의 팀은 고객과 후속 조치를 취하기 위해 GitLab을 떠나거나(또는 통합을 설정할 필요 없이)
시간을 절약합니다.
관련 주제
서비스 데스크 문제 해결
서비스 데스크에 대한 이메일이 문제를 생성하지 않음
이메일이 무시될 수 있습니다. 그 이유는 이메일이 GitLab이 무시하는 이메일 헤더 중 하나를 포함하고 있기 때문입니다.
16.6.0 셀프 관리에서 이메일 수집이 작동하지 않음
GitLab 셀프 관리 16.6.0에서는 mail_room(이메일 수집)이 시작되지 않도록 하는 회귀가 도입되었습니다.
서비스 데스크와 기타 이메일 회신 기능이 작동하지 않습니다.
문제 432257에서 이 문제의 수정을 추적합니다.
우회 방법은 영향을 받은 파일을 패치하기 위해 GitLab 설치에서 다음 명령을 실행하는 것입니다:
리눅스 패키지 (Omnibus)
curl --output /tmp/mailroom.patch --url "https://gitlab.com/gitlab-org/gitlab/-/merge_requests/137279.diff"
patch -p1 -d /opt/gitlab/embedded/service/gitlab-rails < /tmp/mailroom.patch
gitlab-ctl restart mailroom
도커
curl --output /tmp/mailroom.patch --url "https://gitlab.com/gitlab-org/gitlab/-/merge_requests/137279.diff"
cd /opt/gitlab/embedded/service/gitlab-rails
patch -p1 < /tmp/mailroom.patch
gitlab-ctl restart mailroom
도움말