UserVoice와 Slack을 연결하기

서론

이 글은 UserVoice와 Slack을 Zapier을 이용하여 연동하는 방법을 설명합니다.

UserVoice는 세계적으로 많이 쓰이는 고객응대 전용 웹서비스입니다. 개발자가 붙이기 편하도록 HTML위젯, 이메일 연동 등을 제공하고 이용자들끼리 좋은 제안에 Vote도 합니다. 제안된 내용이 진행되면 ticket 발행부터 진행 상황 공유를 통해 보다 이용자들과 가까이 다가갈 수 있습니다.

Slack은 급성장하는 팀워킹 서비스로 채팅을 기본 메타포로 하면서 다른 서비스 연동이나 검색 편의를 끌어올려서 인기를 얻고 있습니다.

Zapier는 다양한 웹서비스 API를 서로 엮어주어 상호간 정보전달이 가능하도록 이어주는 API 브릿징 전문 서비스입니다.

위의 세가지 서비스는 모두 무료로 어느 정도 부족함없이 사용할 수 있으며, 그럼에도 빠른 발전을 꾀하는 인터넷 서비스 회사에게는 매우 큰 편의를 제공합니다.

본론

세가지 서비스 모두 가입해서 계정이 있다는 것을 전제로 합니다.

연동 방법은 간단한데, Zapier에서 둘 사이를 아래 그림처럼 이어주기만 하면 됩니다.
캡처

중요한 것은 다음 내용으로, 뭔가 예쁘게 Slack에 보여주고 싶어서 Slack의 포멧 기준을 참고하여 아래와 같이 만들었습니다. 이렇게 하면 UserVoice에 올라오는 제안이 Slack에 #uservoice-incoming 이라는 채널에 기록됩니다.
캡처

설정이 끝나면 Slack에는 아래와 같이 이쁘게 나옵니다 🙂
문구 마지막에 “클릭”을 누르면 해당 UserVoice 글로 가게 됩니다.

캡처

결론

기존에는 UserVoice에 각종 제안이나 컴플레인이 있으면 모두가 공유하기까지 시간차도 있었고 별도로 로그인을 했습니다. 제안 내용 그대로를 모두가 같이 보고 대화를 나눠야 하는데 그럴 수도 없었지요.

이제는 간단한 Zapier 설정만으로 두 서비스가 연결되면서 팀원들이 유저들의 제안을 편하게 볼 수 있게 되었습니다.

Advertisements

TeamCity에서 안드로이드앱 배포하기

TeamCity는 제가 좋아하는 CI(Continuous Integration)툴, 다시 말해 소프트웨어 빌드 자동화 프로그램입니다. 몇 일 전에 버전 9이 나왔습니다. 무료로는 빌드설정 20개, 에이전트 3개의 제한된 수준으로 사용할 수 있으니 상당히 많은 혜택을 주는 셈입니다. 스타트업들에게는 뒤집어쓸만큼인거죠.

본론으로 들어가서, TeamCity에서 안드로이드 앱을 배포하는 방법을 알아봅시다. 다음의 상황을 가정합니다. 팀 내에서 알파버전 테스트, 즉 개밥주기(Dogfooding)를 할 때 두가지 방법을 사용할 수 있습니다.

  1. 구글 Play스토어가 제공하는 알파버전 배포방법을 이용.
  2. 빌드서버에서 직원들에게 이메일로 apk를 다운로드하도록 제공.
    • 오늘 설명할 방법.
    • 장점: 개발자가 소스코드 push만 하면 끝. 배포는 즉시.
    • 단점: 받는 사람이 매번 새로 깔아줘야 함.
  3. 매번 동료들 핸드폰 똥구멍에 선꽂고 구워주기 (이런건 이제 그만~)

즉, 빌드서버를 이용하는 방법은 양해를 구할 수 있는 팀 내에서 빠른 배포 사이클을 원할 경우 절대적인 장점을 지닙니다. Play스토어를 이용하는 방법은 외부인이 개입되는 클로즈베타에 유용합니다.

이제 다음의 과정을 거쳐서 설정할 것입니다.

  1. git에서 소스 다운로드 및 실행
  2. Build Step 작성: gradle부터 파일정리까지 (총 4단계)
  3. apk를 artifact로 인식
  4. 빌드 성공시 이메일로 알림
  5. 이메일에 원클릭 다운로드 링크 제공

참고: 제 TeamCity 및 안드로이드는 모두 윈도우 기반셋팅입니다. 윈도우에서 안드로이드 코딩하고 윈도우서버용 TeamCity를 설치했으니 다른 플랫폼은 경로나 소소한 셋팅이 다를 수 있습니다.

1. git에서 소스 다운로드 및 실행

자세한 설명은 생략합니다. Version Control Setting에서 git 주소를 연결하시면 됩니다. 또한, Triggers 메뉴에서 VCS Trigger를 만들어서 git이 갱신될 때마다 구동되도록 합니다.

저는 Trigger에 Quiet Period: 180초를 걸어서 push하고 가끔 파일 빼먹을 때가 있어서 급히 넣곤 하니까 3분 후 굽도록 했습니다.

2. Build Step 작성: gradle부터 파일정리까지

2.1 Clean

Build Step의 첫번째로, Gradle Clean을 합니다. 이전에 빌드한 데이터와 꼬일 수 있으니 비워주면 좋습니다.

  • Runner type: Gradle
  • Gradle tasks: clean
  • Additional Gradle command line parameters: --info
  • Gradle Wrapper: Use gradle wrapper to build project → 체크합니다.
  • Stacktrace: Print stacktract → 체크합니다.

설정 스크린샷은 아래와 같습니다. “어? 나보다 항목이 많은데?”라고 하시는 분은 제일 아래 노란색 “Show advanced options”를 클릭하세요. 중간에 Working directory는 git 다운로드 폴더를 임의로 지정했을 경우이며 취향일 뿐입니다.
캡처e1

2.2 gradle assembleRelease

소스를 컴파일하고 apk로 만들기 위한 assembleRelease 명령을 실행합니다. “2.1 Clean”과 거의 유사하며 다음만 다릅니다.

  • Gradle tasks: assembleRelease

센스있는 분이라면, 첫번째 스텝을 실행해보시고 성공하면 Build Steps 표에 나오는 “Copy build steps” 버튼을 이용해서 복사하시면 됩니다.

여기까지 하고 일단 한 번 Run 해서 확인합니다. 빌드 결과를 다음 스텝에서 인식하면 편하기 때문입니다.
여기까지 성공하면 80% 완료한겁니다.

2.3 unaligned 파일 삭제하기

assembleRelease를 하면 apk파일이 두 개 나옵니다- aligned, unaligned. 둘의 차이는 제가 올린 stackoverflow 질답글에서 알 수 있습니다. 결론은 unaligned는 지워도 되는 파일입니다.

  • Runner type: Command LIne
  • Working directory: apk나오는 경로 지정. Working Directory는 우측에 트리 아이콘을 눌러서 지정하세요. 제 경우 project/build/outputs/apk이지만 경우에 따라 다릅니다.
  • Run: Command Executable with parameters 선택.
  • Command executable: del
  • Command parameters: *unaligned.apk

참고: 리눅스나 맥OS용 TeamCity는 다르겠지요. 목적은 같을테니 내용을 파악하여 적용하시면 됩니다.

2.4 Rename (옵션)

다운받는 사람들에게 버전을 명확히 인식시키기 위해 빌드버전이 파일명에 나타나도록 합니다. 그래야 나중에 메신저로 “15버전 받으세요~”라는 식으로 말할 수도 있으니까요.

TeamCity는 한 번 구울 때마다 build.counter라는 값이 1씩 올라가니까 이걸 이용합니다. 위에 2.3과 거의 동일하니 역시 Copy Build Step을 이용해서 복사합니다.

  • Runner type: Command Line
  • Working directory: 2.3과 동일
  • Command executable: rename
  • Command parameters: bapul-release.apk bapul-release-%build.counter%.apk

물론 Command parameter는 맘에 드는 이름으로 지으세요. 저희 회사 이름 그대로 넣지 마시고요.

최종적으로, 빌드스텝 4개는 아래와 같아집니다.
캡처

3. apk를 artifact로 인식

Artifact가 사전에서는 말이 어려운데, 흔히 말하는 “산출물”입니다.
캡처

간단히 한 줄 설정이며, General Settings 메뉴에 들어가서 다음을 설정합니다.

  • Artifact paths: project\build\outputs\apk\bapul-release-%build.counter%.apk

역시 마찬가지로 우측 폴더트리 아이콘을 클릭하여 Step 2.4에 있던 경로를 참고하여 적어줍니다. 이러면 해당 apk 파일이 최종 산출물로 인식되어 원클릭 다운로드가 되도록 할 수 있습니다.

4. 빌드 성공시 이메일로 다운로드 링크 전송

빌드 성공시 서버가 Email을 보내려면 SMTP 설정이 되어있어야 겠지요. SMTP 설정은 사용하시는 메일서비스마다 다르겠고요. 저희는 구글앱스를 쓰는데 다음과 같습니다. 이 메뉴는 Administration > Email Notifier에 있습니다.
캡처

SMTP 설정은 했다치고, Notification은 개인마다 또는 그룹마다로 지정할 수 있습니다. 본인에게 먼저 테스트해보려면, 우상단 자기 profile을 들어간 후, Email Notifier에 “Add New Rule” 버튼을 클릭합니다.

“Builds from the selected build configurations”를 체크한 후 트리에서 원하는 프로젝트를 선택한 후, 우측 체크박스에서는 빌드 성공했을 때만 보내야 하니까 “Build is successful”에만 체크합니다.

아마도 메일이 잘 갈텐데 메일 받는건 다음과 같이 갑니다.

2014-12-13-14-01-25

위에 #15라는 링크를 클릭하면 브라우저가 뜨고 로그인을 하면 teamcity의 프로젝트 화면으로 갑니다. 거기서 Artifacts 탭에 간 후 파일을 선택하고 다운로드를 클릭하면 받아지지요.
그룹이나 특정 사람에게 보내려면 Administration > Users > 특정 사람 또는 Groups에서 해당 소속에게 일괄전송이 가능합니다.

5. 이메일에 원클릭 다운로드 링크 제공 (옵션)

TeamCity에 로그인은 한 번만 하면 그 후엔 자동로그인이 되니까 양해를 구할 수 있지만, 뭔지 알 수도 없는 프로젝트 화면을 팀원들이 보도록 하는건 어쩐지 불친절합니다. 받은 이메일에서 원클릭으로 apk를 받을 수 있도록 해야 할겁니다.

저는 TeamCity에 대해 무한히 좋아하는 마음을 가지고 있지만, 단 하나 부족한게 이메일 템플릿이 고정적이라는겁니다. 즉, Successful 메시지는 하나의 템플릿 파일에만 의존합니다. 그러므로, 이메일 템플릿을 요리하려면, 해당 템플릿에 if문을 넣어서 특정 프로젝트 결과에 대해서만 처리를 해줘야 합니다.

해당 이메일 템플릿 파일은 TeamCity 서버에 다음의 경로에 있습니다.
ProgramData라는 폴더는 숨김폴더임을 주의하세요.
Untitled-1

스크린샷에서 보이는 build_successful.ftl 파일을 수정합니다. 이 템플릿은 “FreeMaker”라는 자바기반 템플릿 언어에 기반합니다. 전체 파일은 제가 gist(클릭:열기)에 올려놓았습니다.

보면 아래와 같은 부분이 추가되었습니다. (제 프로젝트에 맞게 if문을 수정했습니다)

<#-- MODIFICATION START -->
  <#if buildType.externalId = "Android_BapulCube">
    <br>
    <a href='http://www.your-company.net/repository/download/${buildType.externalId}/.lastSuccessful/bapul-release-${build.buildNumber}.apk'>Click here to download APK.</a>
    <br>
  </#if>
<#-- MODIFICATION END -->

참고로, buildType.externalId는 해당 Build Configuration의 ID입니다. 해당 빌드셋팅가서 볼 수도 있고, 주소창에 http://www.your-company.com/viewType.html?buildTypeId=Android_BapulCube 형태로 보이기도 합니다. 빌드셋팅의 고유ID니까 특정 빌드 결과에 대한 것만 받는 경우이며, 다른 센스를 부리자면 project.name=”Android”와 같이 할 경우 Android라고 이름지은 프로젝트의 모든 빌드 결과에 대해 받게 되겠지요.

더 멋지게 꾸밀 분은 TeamCity Notification 설명서를 참고하세요.

여하간, 이렇게 설정하면 아래와 같이 소박하게 다운로드 링크가 나옵니다. “Click here to download APK.”라는 부분 보이시죠? 이제 팀원들은 (로그인을 했다면) 원클릭으로 apk를 다운받고 앱을 테스트할 수 있겠지요.

2014-12-13-14-00-36

더 센스를 부리자면 앱에 업데이트 프로그램을 구동시켜서 할 수도 있을겁니다. 그에 대한 방법은 여기서 다루지는 않겠습니다.

휴~ 끝났습니다.

TeamCity에서 Azure Worker Role Deploy하기

파워셸을 처음 써보느라 거의 5시간 걸려서 해냈네요. 프로그래밍의 재미란 역시 이런것….은 개뿔 옳지 않습니다.

이전 글 TeamCity에서 Azure WebSites Deploy하기에 이은 이번엔 Azure Cloud Worker Role로 Deploy하는 법을 알아봅시다.

Azure Worker Role은 백그라운드 작업에 유용한 것으로, 단점은 지극히 느린 Deploy 시간입니다. 대략 짧게는 4분, 길게는 10분 가량의 시간이 소요되는데, 이렇게 오래 걸리는 이유는 수많은 과정을 거치기 때문이랍니다. 그러니 Visual Studio만 쳐다볼게 아니라 이런건 빌드서버에 맡겨두고 아이돌 음악 두세곡이 흐를 때 즈음 알림을 받는게 더 고상한 삶입니다.

빌드서버란 보통 이런 일을 합니다
빌드서버란 보통 이런 입장입니다

참고로 이 글은 srkirkland의 포스트를 참고했으며, 최근 주요 변경점을 반영했고, 삽질 오류 상황을 덧붙여서 업데이트한 글입니다.

필자가 이미 충분히 인생을 허비했으니 이 글을 따라하는 분들은 영생을 얻길 바랍니다.

Azure Worker Role을 Deploy하기 위해서는 총 3개의 빌드스텝이 필요합니다.
이 글은 TeamCity에서 배포하는 방법에 대한 가이드이며, 다음의 과정을 거칩니다.

  1. 로컬에서 배포테스트
  2. 소스콘트롤에서 Pull / Nuget Restore
  3. MSBuild
  4. 인증파일(.publishsettings) 설정
  5. 파워셸 스크립트
  6. 에러체크
  7. 트리거 설정 (옵션)

사실 빌드서버라는게 하는 일이 뻔합니다. 소스받아 컴파일하고 압축된 결과를 업로드하고 초기구동 스크립트를 실행하는거죠.

1. 로컬에서 배포테스트

로컬 컴퓨터에서 돌리는 Visual Studio의 클라우드 프로젝트에 우클릭하여 Publish를 클릭합니다. 많은 셋팅은 이에 기반하므로 먼저 성공하는지 점검해봅니다. 특히 Worker Role은 소스에 문제가 있는 경우 무한대기에 빠지는 경우도 있으니 일단 가장 기본 소스로 배포 자체가 성공하는지를 점검하는 것이 중요합니다.

2. 소스콘트롤에서 Pull / Nuget Restore

이전 글의 과정 1번, 2번과 동일합니다. 그대로 따라서 첫번째 Build Step인 Nuget Restore까지 만들어주세요.

3. MSBuild

먼저 주의할 점은, 빌드 서버에 동일 버전의 Azure SDK, Azure Cmdlet이 설치되어있어야 합니다. 설치는 Platform Installer를 이용하시면 편합니다.
빌드스텝 하나를 만들고 다음과 같이 설정해주세요.

  • Runner Type: MSBuild
  • Bulid File path: 솔루션 파일
  • MSBuild version: Microsoft Build Tools 2013
  • MSBuild ToolsVersion: 12.0
  • Run platform: x86 (다를 수 있음)
  • Targets: Publish (중요)
  • Command line parameters: /p:Configuration=teamcity_worker

마지막 줄에 /p:Configuration=teamcity_worker란? 이것은 아래 그림과 같이 Start 버튼 옆에 Solution Configuration이라는 콤보박스에 있는 것입니다. 저처럼 한 솔루션에 백그라운드와 상관없는 프로젝트가 있는 경우 괜히 빌드 에러가 날 수 있으므로 Dependency를 확인하고 꼭 필요한 것들만 컴파일 하도록 체크해줍니다.

캡처3

4. 인증파일(.publishsettings) 설정

이게 재미난데, 빌드서버에서 Microsoft Azure PowerShell을 실행하고 아래와 같이 Get-AzurePublishSettingsFile이라고 입력하면, 뜬금없이 브라우저가 뜨더니 로그인을 하라고 합니다. 로그인을 하면 Azure의 구독(subscription)을 선택하게 되고 .publishsettings 파일을 다운받게 해줍니다. 콘솔공포증인 저는 처음에 콘솔입력에 쫄았지만 다행이었습니다.

캡처5

이 파일을 “C:\teamcity\”에 파일명을 짧게 고쳐서 넣습니다. 보안이 걱정되면 보안이 좀 더 좋은 어딘가에 넣어놓으세요. 참고로 빌드서버는 외부접속이 안되도록 하는 경우가 대부분입니다.

5. 파워셸 스크립트

파워셸 스크립트로 Azure에 업로드를 합니다.
우린 지금까지 Nuget restore, MSBuild 빌드스텝을 만들었고, 이제 세번째가 되는 새 빌드스텝을 만들어서 다음의 값을 입력합니다.

  • Runner Type: Powershell
  • Powershell run mode: Any / Bitness: x86 (이건 만든 프로젝트에 따라 맞추세요)
  • Error Output: error (중요)
  • Script: Source Code
  • Script source: 아래 코드를 복사붙이기 한 후 […] 부분을 바꿔주세요. gist에도 올려놨습니다.
  • Script execution mode: Put script into PowerShell stdin with “-Command -” arguments

파워셸 스크립트

$ErrorActionPreference = "Stop"
$subscription = "[Your Subscription Name]"
$service = "[Your Azure Service Name]"
$slot = "staging" #staging or production
$package = "[ProjectName]bin[BuildConfigName]app.publish[ProjectName].cspkg"
$configuration = "[ProjectName]bin[BuildConfigName]app.publishServiceConfiguration.Cloud.cscfg"
$timeStampFormat = "g"
$deploymentLabel = "ContinuousDeploy to $service v%build.number%"

Write-Output "Running Azure Imports"
Import-AzurePublishSettingsFile "C:TeamCity[Your PublishSettings Filename].publishsettings"

function Publish(){
 Write-Output "$(Get-Date -f $timeStampFormat) - Publising Azure Deployment..."
 $deployment = Get-AzureDeployment -ServiceName $service -Slot $slot -ErrorVariable a -ErrorAction silentlycontinue 

 if ($a[0] -ne $null) {
    Write-Output "$(Get-Date -f $timeStampFormat) - No deployment is detected. Creating a new deployment. "
 }

 if ($deployment.Name -ne $null) {
    #Update deployment inplace (usually faster, cheaper, won't destroy VIP)
    Write-Output "$(Get-Date -f $timeStampFormat) - Deployment exists in $service.  Upgrading deployment."
    UpgradeDeployment
 } else {
    CreateNewDeployment
 }
}

function CreateNewDeployment()
{
    write-progress -id 3 -activity "Creating New Deployment" -Status "In progress"
    Write-Output "$(Get-Date -f $timeStampFormat) - Creating New Deployment: In progress"

    $opstat = New-AzureDeployment -Slot $slot -Package $package -Configuration $configuration -label $deploymentLabel -ServiceName $service

    $completeDeployment = Get-AzureDeployment -ServiceName $service -Slot $slot
    $completeDeploymentID = $completeDeployment.deploymentid

    write-progress -id 3 -activity "Creating New Deployment" -completed -Status "Complete"
    Write-Output "$(Get-Date -f $timeStampFormat) - Creating New Deployment: Complete, Deployment ID: $completeDeploymentID"
}

function UpgradeDeployment()
{
    write-progress -id 3 -activity "Upgrading Deployment" -Status "In progress"
    Write-Output "$(Get-Date -f $timeStampFormat) - Upgrading Deployment: In progress"

    # perform Update-Deployment
    $setdeployment = Set-AzureDeployment -Upgrade -Slot $slot -Package $package -Configuration $configuration -label $deploymentLabel -ServiceName $service -Force

    $completeDeployment = Get-AzureDeployment -ServiceName $service -Slot $slot
    $completeDeploymentID = $completeDeployment.deploymentid

    write-progress -id 3 -activity "Upgrading Deployment" -completed -Status "Complete"
    Write-Output "$(Get-Date -f $timeStampFormat) - Upgrading Deployment: Complete, Deployment ID: $completeDeploymentID"
}

#Azure Publish Execution
try{
    Set-AzureSubscription -CurrentStorageAccount [Your Storage Account Name] -SubscriptionName $subscription
    Publish
}catch{
    throw #Rethrow to detect failed build status.
    Break
}

하단의 [Your Storage Account Name]까지 꼼꼼하게 바꿔주세요. 바꿀 값들은 로컬에서 Publish할 때 나오는 창의 Summary에 대부분의 내용이 있습니다.

여기까지 하고 일단 Run을 실행해서 잘 되는지 확인해봅니다.

6. 에러 체크

TeamCity는, PowerShell 스크립트를 실행할 때 오류가 나도 success라고 되는 문제가 있습니다. 하지만, 저는 그 문제를 스크립트 마지막에 throw를 넣는 처리를 했고, 이제 teamcity가 이것을 통해 error라고 인식하게 해야 합니다.

말은 복잡하지만 아래처럼 간단히 체크 하나만 해주면 됩니다.
캡처3

끝났습니다.

7. 보너스: 트리거

저는 이전에 올린 Azure WebSites와 같은 솔루션을 사용하고 있으므로, VCS에서 Worker 프로젝트만 수정해도 WebSites가 구워지고, WebSites만 수정해도 8분가량 걸리는 Worker가 수정되는 문제가 있었습니다.

이를 해결하기 위해서는 Build Trigger Rule을 설정해줍니다.
캡처3
Trigger Rules의 기본규칙은, +는 Include, -는 Exclude이며, 위 그림의 설정을 보건데, /BapulServer/BapulSpreadWorker, /BapulServer/BapulCloudApiService 라는 폴더의 하부에 변화가 생겼을 때만 빌드를 수행합니다. 반대는 -:/폴더경로 식으로 해주면 ‘그 폴더에 대한 변화는 무시한다’는 뜻이 되므로 적절히 조합해서 사용하시면 되겠습니다. 자세한 규칙은 공식문서를 참고하세요.

최종적으로는, 아래 그림과 같이 셋팅이 되어 있을겁니다.
캡처4

그럼 즐거운 하루 보내세요.
레알 끝!

소프트웨어 이슈트래커 선택 #4

이만하면 거의 사유의 흔적 같다.
기존글: #1, #2, #3

YouTrack의 선택은, 써볼 수록 좋은 선택이었다고 생각한다. 깔끔한 UI, 강력한 검색 등 슬슬 손에 익는다.

단축키가 종종 빠릿하게 동작하지 않지만 이것은 1주 후 자동적용되는 버전6에서 강화된다고 한다.

단점이 대두된 것이 Visual Studio와의 연계이다. 이슈 번호를 일일이 적는다는건, 꽤 괴로운 일이다. Visual Studio는 아무렴 Visual Studio Online과 찰떡궁합니다. 그러므로 서버는 Visual Studio Online을 쓰지만 github과 sync가 되도록 하면 그것도 좋겠다는 생각을 했다. 단점은 Visual Studio Online의 hook은 github를 지원하지 않는다.

하여간 노블한 개발환경은 요원하다.

동료들은 꽤 만족한다. 그 이유는 같은 JetBrains사의 IntelliJ, WebStorm과의 궁합이 매우 좋기 때문이다. IDE에서 바로 task 검색이 되고 자동으로 진행중으로 표시해주고 자동으로 finish 처리도 git 작업에 따라 수행된다. 새 일감을 만들거나 현황을 한 눈에 파악하는 경우 외에는 YouTrack을 볼 필요도 거의 없다.

결론적으로,
1~4명: PivotalTracker.
5명 이상: YouTrack.
운영팀과의 통합관리 및 대규모: Atlassian 종합셋트.

이렇게 요약할 수 있겠다.

소프트웨어 이슈트래커 선택 #3

기존 글 링크1, 링크2
오랜 고민 끝에, PivotalTracker에서 JetBrains YouTrack을 우리 조직의 이슈트래커로 사용하기로 했다.

오히려 처음엔 Atlassian JIRA가 유력했지만 선택안했던 이유는, GitHub과의 연동이 별로 좋지 않았다는 점과, UX가 묘하게 어색한 곳이 있었다는 것 때문이다. 사용자로 하여금 뭔가 헤매이게 만들었다. 그 이유는, JIRA는 소프트웨어 개발을 위한 이슈트래커라기 보다는 프로젝트 관리툴의 성격이 더 크기 때문이다. 그래서 JIRA의 상품구성을 보면, 서비스데스크와의 연동 및 소스콘트롤과의 연동을 제공하고 있다. 즉, JIRA 그 자체는 엄밀히 말하면 소프트웨어 이슈트래커는 아니라는거다.

YouTrack을 선택한 이상, 그 장점을 나열해야 겠다.

  1. UX적으로 JIRA보다 깔끔하고 설득력있다.
  2. GitHub과의 연동이 수월하다.
  3. 이미 우리는 TeamCity를 CI(Continuous Integration)툴로 사용하고 있어서 같은 회사 제품으로 연계가 잘된다.
  4. 이미 우리는 IntelliJ, WebStorm 등의 JetBrains 제품군을 사용하고 있다.
  5. 동료들에게 JetBrains에 대한 신뢰가 좋아서 새로운 제품을 도입하기에도 저항이 적다.
  6. 부가적으로, UI는 한국어가 없지만, 의지만 있다면 GitHub에 공개되어 있는 국제화파일을 받아서 만들 수 있다.

물론 단점도 있다.

  1. VisualStudio, XCode와의 연계는 없다시피하다. 이슈ID를 복사붙이기로 commit할 때 처리해야 한다.
  2. 초반 셋팅에 시간이 좀 든다. 특히 Agile 보드는 자유도가 너무 높다는게 단점이기도 하다. Pivotal과 달리 Issue와 Agile보드가 구분되어 있다보니 머리속에서 둘을 연계시켜야 한다.
  3. 디자인이 깔끔한 편이지만 좋은건 아니다. 커스텀이 다 될 것처럼 보이지만 답답한 구석도 많고 낭비되는 공간도 너무 많다.
  4. GitHub의 commit에 따른 변화가 바로바로 리프래시되지 않는다. 이건 좀 실망.
  5. 익스텐션이나 모바일앱이 매력적인게 없다. 뭐 사실 Pivotal도 매력적인건 없었다. 아 그래 없어도 된다. 모바일로 볼 수 밖에 없는 상황에도 일 생각하는건 비참한거다.

한편으로, 근 2년 잘쓰던 PivotalTracker는, 소규모 개인 취미 프로젝트에서는 여전히 활발히 쓸 것 같다. Issue 목록과 Agile 보드를 적절히 합쳐놓은 UX, 빠른 반응, Git연동에 대해 실시간으로 표현해주는 상쾌함. 정말 잘만든 웹서비스다. 다만 3명 이상의 프로젝트에서 서로 열기를 뿜으며 만들 때는 너무 혼잡해진다.

소프트웨어 이슈트래커 선택 #2

현재 바풀은 PivotalTracker로 이슈관리를, 버전콘트롤로 GitHub Private Repo를, CI로는 JetBrains Teamcity를 쓴다.
1. PivotalTracker
Pivotal은 마치 구글앱스와 같아서, 빠른 UI에 간단함으로 소규모 니즈는 거의 다 커버하는데, 한단계만 프로젝트가 복잡해지면 정리가 안된다. 각 파트별로 이슈가 넘쳐나는지라 많이 쓰는 Atlassian JIRA, 내가 좋아하는 JetBrains의 YouTrack을 후보로 놓았다.

  1. JetBrains YouTrack
    우리는 Resharper, IntelliJ, WebStorm, Teamcity을 비롯한 JetBrains 제품군을 적극적으로 쓰는만큼 동사의 YouTrack이 가장 좋을거라 생각했지만, VisualStudio와의 결합성이 과히 별로다. 디자인과 편리함은 JIRA보다 낫다. 탈락.

  2. Atlassian JIRA
    JIRA를 일단 강력 후보로 놓고 어제 깔아봤다. VS용 익스텐션이 있는 것이 주효했다. 완벽하진 않지만 그럭저럭 용서된다. 어차피 Pivotal에서는 전혀 없었던거다. 사용성면에서 JIRA는 모두를 만족하기 위한 불필요한 불편함이 있다. IDE와의 결합성은 가장 낫지만 Pivotal보다 쿨하지 않다는게 불만이다.

  3. Visual Studio Online
    TFS(TeamFoundationServer)는 가장 노하우가 많은 이슈트래커다. 그런만큼 그것의 클라우드버전인 VisualStudio Online이 호환성면에서 가장 낫기도 하지만, 동료들에게 그것을 쓰라고 권하기는 사실 주저함이 있다. 일단 GitHub에서 옮겨야 하는 것도 부담이다. (곰곰히 생각하면 못옮길 이유는 없지만..) 그리고 UI가 깔끔하긴 하지만 시원하진 않다. 일단 JIRA와 함께 후보에 놓고는 있다.

여하간, 내가 충분히 익숙해지면 동료들에게 권해야 겠는데, Pivotal보다 복잡도가 쑥 올라갔다. 이 모든 복잡도의 가장 큰 이유는, Pivotal은 1-page로 모든 것이 끝난다. 페이지 전환이라는 것이 전혀 없다. Gmail이 메일 쓰기화면으로 전환이 안되도록 개선된 것도 다 그런 노력의 일환이다. 다른 것은 상세보기, 보드보기 같은 것들이 있다.

소프트웨어 프로젝트 이슈트래커 선택

소프트웨어 프로젝트 이슈 관리.

우리는 Visual Studio, IntelliJ, WebStorm, XCode를 IDE로 사용하고 있다.
소스콘트롤은 GitHub private repository를 사용한다.

문제는 이슈트래커인데,
현재 PivotalTracker를 열심히 쓰고 있다.

하지만, PivotalTracker에 한계점이 있는게

  1. 태스크간 트리구조나 관계 설정이 거의 안되다시피해서 좋지 않다. 가벼운 프로젝트론 가장 완성도 높지만, 팀이 조금만 규모있는걸 하려면 마구 섞인다.
  2. 그렇다고 프로젝트 여러개를 나눠서 하기엔 너무 거창해진다. 클라이언트, 서버 프로젝트를 각각 운용하는 것보단 하나의 “3.0 개발”이라는 프로젝트 하에서 같이 놓고 볼 수 있는게 낫다.
  3. Visual Studio와 궁합이 좋지 않아서 그냥 매번 브라우저와 IDE를 오가며 수동입력을 한다.

대안은 3가지인데, Jira, YouTrack, VisualStudioOnline 이다. 이슈트래커에 별도로 서버를 운영하기 싫으므로 모두 Cloud버전을 고려한다.

  1. Jira: 가장 새련된 형태가 아닐까 한다. UI 반응도 무척 빠르다. 완성도있는 Visual Studio Connector를 플러그인으로 지원하는데 설치형만 되고 Cloud는 안된다!? 이런…
  2. YouTrack: 내가 개인적으로 사모하는(?) JetBrains의 제품. 우리가 IDE는 제각각이어도 JetBrains 제품을 안쓰는건 XCode밖에 없을 정도다. 단점은 VisualStudio 연동이 안된다.
  3. VisualStudioOnline: 빠르게 발전하고 있고 한때는 이슈트래커 끝판왕이었던 TFS기반이다. 여러 IDE와 괜찮게 연동되는 것 같은데 문제는 MS의 웹제품군은 다들 느리고 시원시원한 맛이 없다.

결론: 하나같이 절대적으로 훌륭한게 없다. 다시 PivotalTracker나 잘쓰는 쪽으로 결정.