Uncategorized

윈폰용 텔레그램 앱의 UI 구조 살펴보기 #1

현재 참가 중인 앱 개발 모임에서 윈폰용 텔레그램 클라이언트인 Kilogram 오픈소스를 분석해 보고 있다. UI 부분의 분석을 맡기로 해서 간단히 살펴본 내용을 공유해 본다.

Entry point

우선 앱의 시작점은 Package.appxmanifest를 살펴보니, UI/Pages/StartPage.xaml로 되어 있다.

image

프로젝트의 UI 폴더와 Pages 폴더의 구성은 다음과 같다.

image
image

StartPage

StartPage.xaml에서 사용자 정의 Namespace를 살펴보면 다음과 같다.

image

이 중 controls의 경우는 DialogListControl과 UserListControl이 쓰이고 있다.

image

DialogListControl는 대화 목록이고, UserListControl은 연락처 리스트로 보인다.

image

그 밖에 프로젝트에서 사용하는 사용자 정의 컨트롤은 아래와 같다.

image

그 밖에 StartPage에는 앱바가 있는데, New, Search, Settings 등의 버튼이 있다. 각각 ChatCreate.xaml, SearchPage.xaml, Settings.xaml 페이지로 연결된다.

image

OnLoaded 이벤트에 아래와 같이 세션 인증이 됐는지를 따져서 안 된 경우 Intro.xaml을 보여준다.

image 

앞서 살펴본 2개의 리스트 컨트롤의 항목을 클릭했을 때에는 DialogPage로 보낸다.

image

단, 대화를 선택했을 때는 선택한 DialogModel 인스턴스를 TelegramSession.Instance.Dialogs.OpenedDialog에 넣고, 연락처를 선택했을 때는 userId를 페이지 인수로 전달한다.

참고로, UI폴더에 속한 Models 폴더의 클래스 구성은 단촐하다.(UI 폴더와 같은 레벨에 Models가 따로 있다.)

image

Intro & Signup

인트로 페이지에서 Signup 페이지로 전달되며, 여기서 Telegram.UI.Flows.Login을 이용해서 로그인을 한다.

image image

image

Login() 메서드에는 flow의 이벤트 처리 핸들러들이 정의되어 있고 마지막에 flow.Start()를 호출한다

image

Telegram.UI.Flows에는 Login 클래스만 존재한다.

image

로그인이 끝나면 다시 StartPage로 돌아간다.

ChatCreate

image

검색창, new group과 new secret chat이 있고, 연락처에 쓰인 UserListControl이 있다. 검색을 할 경우, UserControl에서 검색을 처리한다.

image

new group 버튼은 NewGroup.xaml 페이지로 보내고, new secret chat은 NewSecretChat.xaml로 보내며, UserList를 클릭한 경우는 StartPage와 마찬가지로 UserId를 껴서 DialogPage.xaml로 보낸다.

NewGroup과 NewSecretChat은 모두 UserListControl을 사용하고 있으며, NewGroup의 경우 그룹 이름과 멤버를 입력하는데 FormLatterEditPhoneControl을 사용한다.

image

image

두 페이지는 대화방 생성이 끝나면 StartPage로 보낸다. 아마 이렇게 생성된 그룹이나 대화방은 DialogList에 추가가 되는 것으로 보인다. 각각 TelegramSession.Instance.Api.messages_createChat(…)와 TelegramSession.Instance.EncryptedChats.CreateChatRequest(…)를 호출하여 대화방을 생성한다.

DialogPage

계속…

Xamarin 앱 개발 테스트 #5

사실, Xamarin이 크로스 플랫폼 앱을 개발하는데 가장 뛰어난 툴이라고는 할 수 없다. 단지 크로스플랫폼 앱을 빠르게 만들고 싶다면, Codova를 이용한 하이브리드앱이나 AIR, Corona SDK 같이 완전히 동일한 코드를 실행하는 다른 크로스 플랫폼 도구를 사용하는 것이 나을 수도 있다. 다만, Xamarin의 장점은 다른 언어가 아닌 C#으로 개발할 수 있다는 점, Visual Studio를 이용할 수 있다는 점, 기능 제약이 없는 네이티브 앱을 개발할 수 있다는 점 등이 특징이다.

완전히 동일한 코드를 사용하는 것은 아니지만 최대한 코드 재사용성을 높이는 방법을 살펴보고 얼마나 코드 재사용이 가능할지, 어느 정도 할만한지를 확인하는 것이 이 글의 목적이다.

자료를 조사하면서 Xamarin 크로스 플랫폼 앱을 개발하는 데 있어서, Portable Class Library를 이용해 공용 라이브러리를 만들거나,  Shared 프로젝트를 이용해 코드를 공유하는 방법 등을 이용할 수 있다는 것을 알게 되었다.

Portable Class Library(이하 PCL)는 Windows Phone 7 시절에 서로 다른 .NET 프로젝트에서 이식 가능한 라이브러리를 만들 수 있도록 한 것이고, Shared 프로젝트는 Universal Windows App에서 Windows/Windows Phone 프로젝트간 코드 공유를 위해 나온 것이다. Universal Windows App을 위해서 나온 것이지만, 다른 C#, C++, WWA/JS 프로젝트에서도 사용할 수 있도록 하는 Shared Project Reference Manager라는 VS 확장기능도 있다. PCL과 Shared 프로젝트는 개념이 서로 다르다. 두 가지의 차이에 대해서 설명한 글도 있는데 내용을 요약하면 다음과 같다.

  • PCL은 공통 API만 사용 가능하고 플랫폼 고유의 코드를 추상화 레이어 없이는 사용할 수 없는 반면, Shared 프로젝트는 플랫폼 고유의 코드를 사용할 수 있고 XAML UI도 공유할 수 있다.
  • PCL과 Shared 프로젝트는 컴파일과 배포 시점에 완전히 다르게 동작한다. PCL은 계약과 구현에 의해 컴파일할 수 있으나, 빌드와 배포 시점에 플랫폼 고유 버전이 사용된다. Shared 프로젝트는 그 것이 속해 있는 부모 프로젝트와 부모의 레퍼런스에 따라 컴파일하고 배포된다.
  • 글쓴이(Xamarin Developer Evangelist)는 PCL은 라이브러리 개발자, Shared 프로젝트는 앱 개발자를 위한 것이라고 생각하지만, 앱 개발자의 취향에 따라서 PCL 선택할 수 있지만, PCL의 제약으로 인해서 Shared 프로젝트를 더 많이 쓸 생각이라고…

PCL과 Shared 프로젝트를 함께 쓰는 것도 괜찮은 것 같다. System.Net.Http와 같이 PCL 버전으로 만들어진 라이브러리를 사용하면서 Shared 프로젝트에 공유 코드를 담는 방식으로 구현하는 것이 좋겠다는 생각이 든다.

먼저 Xamarin 크로스 플랫폼 앱 개발 문서에도 나와 있는 PCL을 이용하는 방법에 대해서 살펴보고자 한다. 이전 글에서 3가지 코드 공유 옵션을 간단히 살펴 보았지만, 그 중에서는 PCL을 만들어서 공유 컴포넌트를 만들어 사용하는 것이 가장 재사용성이 높다고 생각된다. (File Linking 방식은 Shared 프로젝트로 대체 가능하다.)

참고로, Visual Studio 없이 Xamarin Studio에서 PCL을 사용하려면 Portable Library Tools가 필요하다.

Visual Studio에서 기존 VS 솔루션에 Portble Class Library 프로젝트를 새로 추가하면 아래와 같은 화면이 나온다. Xamarin이 설치되어 있으면 Targets 리스트에 Xamarin.Android와 Xamarin.iOS가 나오게 된다.

 image

PCL에서 코드를 작성하면 같은 API라도 IntelliSense로 접근 가능한 옵션이 다르게 나온다. 아래는 Xamarin용으로 사용하는 프로파일과 기본 프로파일의 비교이다. 우측 스크롤바를 통해 비교할 수도 있지만, 각각 14개(PCL) vs 40개(일반적인 프로젝트)의 클래스가 사용 가능하다.

이러한 이유로 사용 가능한 API에 상당한 제약이 있다. 아래는 PCL을 만들 때 참고할 수 있는 지원 기능 리스트이다. (출처)

image

PCL을 사용할 때는 여타 라이브러리와 마찬가지로 아래와 같이 프로젝트 레퍼런스에 추가하여 사용한다.

아래 솔루션 구성을 보면 맨 아랫 부분에 PCL 프로젝트가 있고, Reference 폴더에 PCL이 추가된 것을 볼 수 있다.

PCL 사용 방법은 살펴보았지만 실제로 포팅이 잘 될지는 모르겠다. Universal Windows  App은 아니지만, Silverlight로 만들어진 앱을 포팅하는 가이드도 있긴 하다.

이 중 Android로 포팅하는 것을 참고로 하여 기존에 Windows Phone 8.1 앱 개발 튜토리얼에 나오는 FlickrSearch라는 Universal Store App을 한번 포팅해보고자 한다.

image image

FlickrSearch는 Flickr Open API를 이용해서 특정 키워드(flower)로 검색한 이미지 결과를 GridView에 뿌려주는 Universal Windows App 앱이다. 두 앱은 완전히 동일한 MainPage(xaml/cs) 코드로 동작한다.

먼저, Xamarin’s .NET Mobility Scanner라는 웹사이트 툴을 이용해서 dll이나 exe 파일을 검사하여, 코드를 얼마나 재사용 가능한지를 살펴보는 것을 권장하고 있다. 아래는 FlickrSearch 앱의 Phone 패키지 폴더에서 exe 파일을 넣고 돌려본 결과이다.

image

예전에 다른 Windows Phone Silverlight 앱을 넣었을 때는 61%가 나왔는데, 보통 60~70% 정도의 결과가 나오는 것 같다. 그런데 실상 결과 리스트를 보면 항목이 너무 많이 나와서 이걸로 포팅하는데 얼마나 도움이 될까 싶기도 하다.

FlickrSearch 솔루션에 Android 포팅을 위해서 FlickrSearch.Android라는 이름으로 Android Application 프로젝트를 추가하고, 여기를 참고하여 FlickrSearch.Shared 프로젝트를 레퍼런스로 추가하였다. 이 때 App.xaml.cs 파일과 TemplateUtility.cs는 Xamarin에서 실행되지 않으므로, 코드 전체를 #if NETFX_CORE ~ #endif로 처리해 주었다.(이럴꺼면 왜 Shared 프로젝트? 라고 생각할 수도 있지만, 일단 Windows/Windows Phone 프로젝트에서 사용하기도 하고, FlickrSearcher.cs 파일은 Android에서도 재사용할 수 있다.)

image

FlickrSearcher.cs 파일이 실제로 Flickr API를 호출하는 클래스인데, 이 프로젝트에서 유일하게 재사용 가능한 코드이다. 그런데 원래 예제에서는 Windows.Http를 사용하고 있다. 따라서 Xamarin.Android에서는 사용할 수 없고, 다행히(?) PCL로 제공되는 System.Net.Http 를 사용할 수 있기 때문에 이 것으로 바꾸어 주어야 한다. 여기서 PCL 버전의 System.Net.Http을 찾을 수 있었다.

앞서 PCL과 Shared 프로젝트를 함께 쓰는 것이 괜찮다고 언급하였는데, 이처럼 Shared 프로젝트에 Application/UI 로직을 제외한 코드를 넣고, 타 프로젝트와 함께 사용하거나 이미 만들어져 있는 PCL만 참조로 추가하여 개발하는 방식이 포팅하기에는 편리해 보인다.

Shared 프로젝트의 흥미로운 점은 현재 실행되는 부모 프로젝트의 레퍼런스를 따라가기 때문에 FlickrSearch.Android 프로젝트의 레퍼런스에만 PCL을 추가해 주면 된다는 점이다. Universal Windows App에서는 PCL 추가 없이 System.Net.Http를 사용할 수 있다.

FlickrSearch.Android 프로젝트에서 PCL을 이용한 FlickrSearch 클래스로 Flickr 데이터를 잘 가져오는지 테스트해봤다.
image

일단 앱이 단순해서 필요한 코드는 쉽게 이식할 수 있었는데, 사실 좀 더 복잡한 프로젝트라고 하면 상당히 많은 코드에서 대체 라이브러리를 찾거나 직접 구현하는데 시간을 들여야 할 듯 싶다. Application/UI Layer는 완전히 새로 만들어야 하기 때문에 앱에 따라서는 이 부분도 상당한 시간이 걸릴 수 있다.

다음 글에서 Android의 GridView를 이용해서 이 데이터를 사용하여 UI를 구성하는 부분을 좀 더 살펴보도록 하겠다.

Xamarin 앱 개발 테스트 #4

앞서 3편의 포스트를 통해 기본 Xamarin.Android 튜토리얼을 살펴보았다. 이번 글에서는 Xamarin의 본래 기능인 크로스 플랫폼 앱 개발과 관련한 내용을 좀 더 살펴보고자 한다.

Xamarin 문서에 보면 Android, iOS, Windows Phone 등 서로 다른 플랫폼 앱을 어떻게 구현하는지에 대한 기본적인 이해를 돕는 내용들이 있다. 내용이 많아서 몇 가지 흥미로운 부분만 발췌해본다.

먼저 Xamarin 플랫폼의 구성요소를 살펴보면 다음과 같다.

  • C# language – Allows you to use a familiar syntax and sophisticated features like Generics, Linq and the Parallel Task Library.
  • Mono .NET framework – Provides a cross-platform implementation of the extensive features in Microsoft’s .NET framework.
  • Compiler – Depending on the platform, produces a native app (eg. iOS) or an integrated .NET application and runtime (eg. Android). The compiler also performs many optimizations for mobile deployment such as linking away un-used code.
  • IDE tools – The Xamarin Studio IDE and the Xamarin plug-in for Visual Studio allow you to create, build and deploy Xamarin projects.

개발툴을 Xamarin Studio(이하 XS)나 Visual Studio(이하 VS)를 사용하는데, Xamarin Studio는 무료 버전에서도 쓸 수 있고 Visual Studio 플러그인은 유료 버전 라이센스가 있어야 한다.

다음은 컴파일이 어떻게 이루어지는지에 대한 설명인데 그냥 참고만 하자.

  • iOS – C# is ahead-of-time (AOT) compiled to ARM assembly language. The .NET framework is included, with unused classes being stripped out during linking to reduce the application size. Apple does not allow runtime code generation on iOS, so some language features are not available (see Xamarin.iOS Limitations).
  • Android – C# is compiled to IL and packaged with MonoVM + JIT’ing. Unused classes in the framework are stripped out during linking. The application runs side-by-side with Java/Dalvik and interacts with the native types via JNI (see Xamarin.Android Limitations).
  • Windows Phone – C# is compiled to IL and executed by the built-in runtime, and does not require Xamarin tools. Designing Windows Phone applications following Xamarin’s guidance makes it simpler to re-use the code on iOS and Android.

iOS는 C#이 ARM assembly language로 컴파일 되는 대신, runtime 코드 생성을 허용하지 않으므로 Generic과 같은 기능 사용에 제약이 있다고 한다. Android는 MonoVM과 JIT’ing이 포함되며, Java/Dalvik과 병행 실행되며, JNI를 통해 네이티브 형식과 상호작용한다. 윈폰은 중간 언어(IL)로 컴파일 후 내장 런타임에 의해 실행되며 별도의 Xamarin 툴이 필요 없다.

다음 도표는 개발 환경에 따른 플랫폼 지원이다.

image

Windows Phone 앱은 Windows-VS(이하 VS)에서만 지원하고, iOS 앱은 Windows-VS에서 개발/배포만 가능하다. 즉, 3가지 플랫폼을 모두 개발하고 테스트하려면 Mac OS X, Windows가 모두 필요하다.

UI 개발의 경우는 Windows에서 3가지 모두 작업할 수 있다. Windows Phone은 VS와 Blend에서 작업 가능하고, 나머지 2가지 플랫폼은 VS와 XS에서 모두 작업 가능하다고 한다.

크로스 플랫폼 앱에서 코드를 공유하는 방식은 3가지 옵션이 있다.

  • 각 앱 프로젝트에 파일 링크 – C# 파일을 하나 만들어서 각 프로젝트에 링크로 추가하는 방법
  • 플랫폼 고유의 라이브러리 프로젝트 – PCL로 구현하기 어려운 경우에, 같은 기능을 하는 라이브러리를 각 플랫폼 별로 구현
  • 포터블 클래스 라이브러리(PCL) – 서로 다른 CLI 플랫폼에서 공용으로 사용할 수 있는 PCL의 사용

솔루션의 구성은 다음과 같이 하는 것을 권장한다.

Shared Code 영역은 Core Project로 만들어서 Business Layer 이하의 공유 코드들을 포함하고, 각 플랫폼 앱 별로 Application Layer/UI Layer를 포함하는 별도의 프로젝트를 구성한다.

Core 프로젝트의 구성 예

Core 프로젝트의 구성 예(Data Layer, Data Access Layer, Business Layer 등을 확인할 수 있다)

Android와 iOS 프로젝트의 구성 예(Application Layer나 UI, Assets 등을 포함하고 있다.)

여기까지 Xamarin의 크로스 플랫폼 앱 개발 기본 및 코드 공유 전략 등을 살펴보았는데, 구체적인 샘플이나 사례를 가지고 살펴봐야 좀 더 실제적인 사용 가능 여부를 파악할 수 있을 듯 하다.

Xamarin 앱 개발 테스트 #3

이번에는 튜토리얼을 따라서 2개 이상의 스크린을 갖는 Android 앱을 만들어 본다. Android의 앱 구성 요소들을 나타낸 그림인데, static main이라는 함수가 앱의 시작점이 되고, Activity와 Service가 스크린을 구성한다고 한다.

_995

Intent는 메시지를 보냄으로써 어떤 일이 수행되도록 한다. 주로 Activity를 실행하는데 사용된다. 이 글을 Xamarin에 초점을 맞춰서 살펴보려고 하므로, 좀 더 자세한 내용은 튜토리얼을 참고하자.

Android의 설정은 AndroidManifest.xml에 포함되어 있으며 모든 앱은 이 파일을 포함해야 한다. 컴포넌트 등록, 권한 요구, 버전 호환성 등의 정보를 포함하여 자세한 내용은 여기서 참고 가능하다.

샘플로 만들 앱은 버튼을 클릭했을 때 두 번째 Activity를 불러오는 앱이다.

	[Activity (Label = "HelloMultiScreen", MainLauncher = true)]
	public class FirstActivity : Activity
	{

먼저 MainActivity(튜토리얼 상에는 Activity1으로 나와 있음) 로 되어 있는 클래스 명을 FirstActivity로 변경하였는데, 바로 위에 있는 ActivityAttribute에 대해서 설명하고 있다. 이 것은 앱이 컴파일 될 때, apk 파일에 들어가는 AndroidManifest.xml 파일을 수정하여 실행할 Activity를 설정한다고 한다. 수정된 AndroidManifest.xml 파일은 다음과 같다.

<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
package="hellomultiscreen.hellomultiscreen" >
    <uses-sdk android:minSdkVersion="11" />
    <application android:icon="@drawable/icon"
        android:label="HelloMultiScreen">
        <activity android:name="FirstActivity"
            android:label="HelloMultiScreen">
            <intent-filter>
                <action android:name="android.intent.action.MAIN" />
                <category android:name="android.intent.category.LAUNCHER" />
            </intent-filter>
        </activity>
    </application>
</manifest>

<intent-filter>가 있고, <action>, <category> 등이 설정되어 있는 것을 확인할 수 있는데 이 부분이 앱의 시작 지점을 나타낸다.

Activity를 변경하는 구문은 다음과 같다. StartActivity 메소드를 이용하는데 이 것은 원래 StartActivity를 오버라이드하여 Activity 타입을 받도록 한 것이라고 한다.

showSecond.Click += delegate {
    StartActivity(typeof(SecondActivity));
};

원래 방식은 다음처럼 호출한다고 한다.

var second = new Intent(this, typeof(SecondActivity));
StartActivity(second);

다음으로는 이동할 새로운 Activity를 만들어야 한다.

새로운 C# 파일로 SecondActivity.cs 라는 이름의 Android Activity 파일을 만들고, Resources/layout에는 Second.axml 파일을 추가한다. Second.axml의 파일에는 다음과 같이 TextView 하나를 추가하였다.

<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:orientation="vertical"
    android:layout_width="fill_parent"
    android:layout_height="fill_parent">
    <TextView
    	android:id="@+id/screen2Label"
    	android:layout_width="fill_parent"
    	android:layout_height="wrap_content"
    	android:text="Hello second activity" />
</LinearLayout>

그리고, SecondActivity.cs의 OnCreate 메소드 안에 SetContentView를 추가해야 한다.

SetContentView (Resource.Layout.Second);

이렇게 하면 Activity의 이동은 간단히 구현이 가능하다.

image

추가로 아래와 같이 Intent 인스턴스의 PutExtra 메소드를 이용하면 Activity 간 데이터 전달을 할 수 있다.

showSecond.Click += delegate {
    var second = new Intent(this, typeof(SecondActivity));
    second.PutExtra("FirstData", "Data from FirstActivity");
    StartActivity(second);
};

PutExtra()는 문자열 뿐 아니라 다른 타입들도 전달할 수 있는 오버로드들을 포함하고 있다. 전달 받은 데이터는 SecondActivity에서 다음과 같이 사용할 수 있다.

var label = FindViewById<TextView> (Resource.Id.screen2Label);
label.Text = Intent.GetStringExtra ("FirstData") ?? "Data not available";

지금까지 멀티 스크린 앱에 대해서 살펴보았다. Activity의 Intent, 그리고 Layout을 통해서 UI에서 화면 전환을 어떻게 처리하는지를 살펴보았는데, Xamarin과 C#을 이용해서 쉽게 구현할 수 있음을 확인할 수 있었다.

Xamarin 앱 개발 테스트 #1

마이크로소프트에서 본격적으로 Xamarin으로 크로스플랫폼 앱 개발을 할 수 있다고 홍보하고 있어서, Xamarin과 C#으로 크로스플랫폼 앱을 개발하는 것이 얼마나 할만한 것인지 테스트를 해보고자 한다.

우선, Xamarin의 기초적인 내용을 파악할 겸, 현재 Xamarin 사이트에서 진행 중인 공짜 C# 티셔츠 프로그램에 참여해보았다!

먼저 Xamarin for Windows를 설치한 후에, GitHub의 Xamarin Store app의 소스를 가져오고, 솔루션 파일을 열어서 실행을 하면 된다. PC에서는 iOS 쪽 앱은 실행해 볼 수 없으므로, Android 앱만 실행해 보았다. 처음 실행하면 에러가 나는데, 앱 용량 제한에 걸려서 무료 버전으로는 실행할 수가 없다. 따라서, 체험판 버전을 활성화 한 후에 실행해야 하는데, Xamarin Studio에서는 체험판을 활성화 하는 방법을 찾지 못해서 결국 Visual Studio에서 한번 열면 나오는 창에서 Trial 라이센스로 변경하였다.

image

앱을 실행하면 티셔츠를 공짜로 구매할 수 있는 앱이 나온다. 한번 실행해서 장바구니에 티셔츠를 넣고 구매하려고 하면, 소스코드에서 Xamarin 계정 이메일을 수정 후에 다시 오라고 한다. 위 스크린샷과 같이 LoginFragment.cs 에서 XamarinAcountEmail의 값을 본인의 Xamarin 계정으로 변경하고 다시 실행하면 주문을 계속 할 수 있으며, 주문할 때 주소를 물어보는데 여기에 주소를 넣고 주문을 마무리할 수 있다.(그런데 한국 주소를 넣어도 배송이 될런지 모르겠다. 티셔츠를 받으면 업데이트 하겠다.)

  • Xamarin을 실행하기 위해서는 Android 개발도구가 필요하다.
  • 왠만한 프로젝트를 하려면 유료 라이센스가 필요한데, 이 가격이 상당한데다 연단위의 구독을 하게 되어 있다. (참고)  MSDN 구독자는 90일 체험판과 할인이 있는 듯 하다.
  • Visual Studio에서 개발을 하려면 Business 이상의 라이센스가 필요하다.Trial로 해보고 꼭 필요할 때 구매하거나, 무료 버전의 Xamarin Studio를 가지고 하되 용량 제한을 피할 궁리를 해봐야 할 듯 싶다.

Team Foundation Service을 비공개 Git 저장소로 사용하기

GitHub를 사용하다 보면 Private 프로젝트는 유료라서 아쉬운 부분이 있다. 오픈소스 프로젝트의 경우는 문제가 되지 않지만, 비공개 프로젝트의 경우는 소스가 공개할 수 없기 때문에 어쩔 수 없이 유료로 전환을 하게 된다.

꼭 GitHub를 고집해야 하는 게 아니면 Private 팀 프로젝트가 무료(5명까지)인 Team Foundation Service(이하 TFS)를 사용하는 것도 좋은 방법이다. Microsoft 에서 제공하는 서비스이지만, 꼭 Visual Studio나 Windows를 사용하지 않는 프로젝트도 Git을 소스 제어 솔루션으로 쓴다면 TFS를 유용하게 쓸 수 있다.

몇 가지 개인 프로젝트를 TFS에서 사용해 보고 있는데 간단히 그 방법을 공유하고자 한다.

1. 우선, TFS 사이트에서 가입을 한다. Microsoft ID가 필요하다.

Sign up for free 클릭

Sign up for free 클릭

2. 향후에 Git 클라이언트나 웹브라우저에서 접속 가능한 원격 저장소의 서브 도메인을 결정한다.

_blog4

3. Microsoft ID(구 Live ID)로 로그인을 한다.

live.co.kr 이나 live.com, 또는 hotmail.com 계정

live.co.kr 이나 live.com, 또는 hotmail.com 계정

4. 계정 개설이 완료되면 New team project + Git 을 클릭해서 새로운 Git 기반 프로젝트를 생성한다.

_blog6

5. 새로운 프로젝트 이름과 설명을 입력하고 Create Project를 클릭한다.

참 쉽죠잉~(언제쩍 개그;)

참 쉽죠잉~(언제쩍 개그;)

프로젝트 생성 완료

프로젝트 생성 완료

6. Navigate to Project를 눌러서 프로젝트로 이동한 후, CODE 탭으로 이동하면 아래와 같은 메시지를 볼 수 있다.

비어있는 저장소로 시작할 것인지? 기존 로컬 저장소를 Push할 것인지?

비어있는 저장소로 시작할 것인지? 기존 로컬 저장소를 Push할 것인지?

만약 Git을 이미 사용하고 있고, 사용방법에 익숙하다면 Git 명령어를 위와 같이 직접 실행해서 시작하면 된다.

여기서 부터는 Git을 처음 사용하는 개발자들을 위해서 계속해서 로컬에 있는 프로젝트에 Git 설정을 해서 TFS에 올리는 것까지 다뤄보려고 한다.

7. 여기서 Windows용(또는 Mac, Linux용) Git을 다운로드해서 설치한다. (Windows의 경우, 설치 중에 PATH에 등록할 것인지 물어보는 부분이 있는데 기본 옵션이 등록하지 않도록 되어 있으므로 PATH에 등록하는 걸로 선택해서 설치하면 나중에 프로젝트 폴더에서 git 명령어를 쓸 수 있어서 편리하다.)

8. Git 설치가 완료되면, 로컬의 소스가 저장되어 있는 폴더로 이동한 후 git init을 실행한다.

소스 폴더에서 git bash 실행하거나, PATH 등록 후 CMD 툴에서 git 명령어 실행 가능

소스 폴더에서 git bash 실행하거나, PATH 등록 후 CMD 툴에서 git 명령어 실행 가능

git init 실행해서 해당 폴더에 git 소스 제어 초기화

git init 실행해서 해당 폴더에 git 초기화

9. 다시 아까 TFS 사이트에서 알려준 대로 git 명령어를 실행해서 원격 저장소로 소스를 Push 하면 된다.

TFS 프로젝트의 CODE 페이지에서 이 부분을 복사

TFS 프로젝트의 CODE 페이지에서 이 부분을 복사

오른쪽 클릭이 안되면 이렇게 붙여넣기

오른쪽 클릭이 안되면 이렇게 붙여넣기

10. 다음과 같이 Push 명령어 입력해서 마무리

git add *
git commit -m "initial commit"
git push origin master

이 때 username과 password를 물어보는데, TFS의 계정 정보를 입력하고 만약 인증에 실패하는 오류가 나오면 TFS 사이트의 프로필(우측 상단 사용자 이름-My Profile)에서 enable alternate credential을 클릭해서 아이디/패스워드를 설정한 후 다시 해보면 된다.

좀 더 자세한 Git 사용법은 여기를 참고