System Compleat.

'GitHub'에 해당되는 글 2건

  1. Github, Hugo, Concourse, CF를 사용한 블로그의 CI/CD
  2. Github with Xcode4

Github, Hugo, Concourse, CF를 사용한 블로그의 CI/CD

Techs


(younjin.jeong@gmail.com, 정윤진) 


최근 많이 사용하는 블로그 도구 중 하나가 바로 Hugo (http://gohugo.io) 이다. 이전에 "블로그" 라고 하면 기본적으로 호스팅 업체 또는 대형 포털에서 제공하는 블로깅 도구를 사용하거나, 또는 제로보드 기반의 게시판이 달린 간단한 웹의 형태로 구성하는 경우가 많았다고 한다면, 최근 몇년 전 부터는 Static Web Site 를 구성해서 사용하는 것이 일반적이다. Static 웹 사이트는 기본적인 개념으로는 JSP 로 구성된 웹 사이트의 첫 페이지를 html 로 구워서 사용하는 것과 유사한 개념이라고 보면 된다. 즉, 각 Static 웹 사이트 도구가 지원하는 언어를 사용하여 컨텐츠를 만들면 '파일' 기반으로 된 페이지를 슝슝 만들어 주고, 이렇게 만들어진 웹 서비스용 파일들은 Github 가 제공하는 무료 웹 페이지 도구나, 아마존의 S3 + CloudFront 를 사용하거나, 또는 웹 서버를 만들어서 서비스 할 수 있다. 당연하지, 이것들은 public 디렉토리의 html 과 css, js, 그런 파일들 이니까. 


블로그의 제작은 보통 마크다운이라는 도구를 사용한다. 간단한 YAML 비스무리한 문법에 맞추어 컨텐츠를 작성하면 페이지가 슝슝 생긴다. 구성 및 사용 방법에 대해서는 Hugo 의 홈페이지를 참조하면 되겠다. 



조금 살펴보다 보면, 각종 theme 를 지원하는 것을 확인할 수 있다. 사실 default 로 제공되는 것은 약간 그런 어떤 허전한 느낌적인 느낌이 있으므로, 보통은 테마를 적용하는 것을 권고한다. 테마는 다른 사람이 만들어 둔 것을 사용하거나, 아니면 내가 직접 만들어서 사용할 수 도 있다. 사실 말이 블로그지 원한다면 제품 관련 페이지를 만들거나, 내 홈페이지를 만들거나, 뭐 어쨌든 웹으로 만들 수 있는건 다 만들 수 있겠다. 이것은 여담이지만 Static 기반의 서비스라고 해도 AWS의 DynamoDB 나 Kinesis, SQS 와 같은 도구를 JavaScript 로 연동하여 데이터를 수집하거나 게시판을 구현하거나 덧글 시스템을 구현하거나 하는 것들이 가능하다. "에이, 그럼 JavaScript SDK에 Credential을 제공해야 하는데 그것이 어떻게 동작해요" 하시는 분들은 AWS가 제공하는 Playground 에서 한번 원리를 확인해 보시길. Web Identity Federation 이라 불리곤 한다. 링크는 여기. (어머 친절도 하지) http://blogs.aws.amazon.com/security/post/Tx1XTHT1VJ1SQLX/New-Playground-App-to-Explore-Web-Identity-Federation-with-Amazon-Facebook-and-G



어쨌든 오늘 소개할 내용을 간단히 리스트업 하면 아래와 같다. 


- Github 

- Concourse 

- Pivotal Web Services (Signup 하면 60일 무료, 카드 정보 따윈 필요 없음:  https://run.pivotal.io) 



다시 돌아가면, 블로그라는 것이 블로그 만으로 사용되기 보다는 일종의 뉴스 서비스와 같은 형태로 만들수도 있을 것이다. 예를 들어, 일종의 팀 블로그를 운영하려고 할때 보통은 워드프레스로 구성하고 여기에 포스팅을 할 수 있는 사람들을 선정하여 권한을 주고 뭐 그런 일반적인 3 tier 기반의 구성을 생각해 볼 수 있다. 무엇보다 풍부한 테마와 플러그인등을 사용해 S3나 CloudFront 도 연결할 수 있고 디자인도 맘대로 바꿀 수 있을 가능성이 많다. 즉 편리하다. 하지만 블로그의 사용성을 생각했을때, 데이터베이스가 꼭 필요한가, 그리고 그 데이터베이스가 항시 구동해야 하는가 게다가 그럼 그 데이터베이스가 죽으면 어떻게 되는가 등등등 생각만 해도 꼬리에 꼬리를 무는 영어 문제들이 계속 나타난다. 아 그러니까 결국 우리는 그런거 필요 없고, 웹 페이지를 통해 정보만 전달하면 되겠다 하는 목적이 발생할 수 있다. 즉, 협업해야하고, 그렇게 만들어진 컨텐츠가 이상이 없는지 테스트를 해야 하고, 그리고 문제가 없을때 스테이징에 배포를 해서 살펴보고, 그렇게 컨텐츠들이 적당한 시점에 누적 되었을때 프로덕션에 릴리즈를 한다. 


어디서 많이 들어본 과정 아닌가? 그렇다 바로 개발, 테스트, 그리고 배포에 대한 이야기다. 그리고 여기서는 그런 도구를 이를 테면 신문사와 같이 수많은 기자들이 작성한 기사들이 특정 시점, 그러니까 매일 아침 4시라던가 또는 특정 시점 없이 지속적으로 배포와 수정이 발생하는 경우 저렴하게 사용할 수 있는 도구가 되는 것이다. 게다가 매우 빠르지. 



간단하기는 하지만, 우리 Pivotal의 엔지니어링 블로그가 그런 형태의 협업 구조로 동작하고 있다. 

http://engineering.pivotal.io/


그리고 이 블로그는 아래의 Github 에 메인 좌표를 가진다. 

https://github.com/pivotal/blog


Github 에 대해서는 별도의 설명을 하지 않겠다. 중요한것은 이 블로그가 Hugo 기반의 이며, Github 기반에서 동작하고 있고, 스테이징과 프로덕션의 단계를 가진다는 것이다. 


두번째로, PWS 에 대해서 설명을 하자면, Cloud Foundry 의 가장 최신 기능이 적용 되어 있고, AWS의 us-east-1에서 동작중인 Pivotal Made CF 서비스다. 회사 계정으로 가입하면 바로 사용해 볼 수 있으며, 사용 방법 또한 간단하다. 계정 생성 이후 CLI 도구를 사용해 로그인을 마치고 나면 cf 라는 도구를 사용해서 다양한 커맨드를 사용할 수 있는데, 여기에서 cf buildpacks 라는 커맨드를 사용하면 사용가능한 다양한 빌드팩이 나온다. 빌드팩이 무언고 하는 설명따위 집어 치우고 output 을 보면 대충 이게 뭔지 아마 알 수 있을것이다. 


$ cf buildpacks

빌드팩 가져오는 중...


buildpack              위치   사용   잠김    파일 이름

staticfile_buildpack   1      true   false   staticfile_buildpack-cached-v1.3.6.zip

java_buildpack         2      true   false   java-buildpack-offline-v3.6.zip

ruby_buildpack         3      true   false   ruby_buildpack-cached-v1.6.15.zip

nodejs_buildpack       4      true   false   nodejs_buildpack-cached-v1.5.10.zip

go_buildpack           5      true   false   go_buildpack-cached-v1.7.3.zip

python_buildpack       6      true   false   python_buildpack-cached-v1.5.5.zip

php_buildpack          7      true   false   php_buildpack-cached-v4.3.9.zip

liberty_buildpack      8      true   false   liberty_buildpack.zip

binary_buildpack       9      true   false   binary_buildpack-cached-v1.0.1.zip



이들 중, staticfile_buildpack 을 사용하게 되면 이런 static 형태의 웹 사이트를 서비스 할 수 있다. 물론 CDN을 연결해서 사용할 수 도 있겠다. 당연한 이야기지만, 다른 다양한 언어로 개발하게 되면 위에 걸리는 것들 중 하나랑 합쳐져 executable 형태가 되고, 다시 이것은 컨테이너에 쏙 들어가서 다이나믹하게 라우팅 되고 밸런싱 된다. 즉, 헬스 체크 구성 그따위거 필요 없다는 말이고 그냥 cf push 하고 컨테이너가 10개든 1000개든 알아서 서비스에 등록하고 밸런싱 한다는 말. 


그리고 여기에 오늘의 핵심이라고 할 수 있는 Concourse 라는 도구를 사용한다. 사실 아직까지 무언가 엄청난 기능을 넣은 것은 아니지만, 이 도구는 CI/CD 도구로서 지정된 소스, 이를테면 Github 와 같은 소스로 부터 코드를 가져다가, 원하는 테스트를 마구마구 지지고 볶고 돌린 다음 그 다음 동작을 구성하거나 또는 스테이징에 배포하거나 또는 Pivotal Tracker 에 후킹 메세지를 보내거나 또는 다른 Github 레포에 빌드를 올린다거나 뭐 그런 원하는 동작을 Docker 기반으로 수행할 수 있다. 물론 대규모 개발 그룹에서는 이를 워커로 분리해서 사용할 수 도 있고, 개발자는 이런 회사가 가진 테스트 파이프라인에 본인의 코드가 문제없이 통과 할 지의 여부에 대해 로컬에 vagrant 로 구성해서 직접 돌려볼 수 도 있겠다. 



어쨌거나 오늘의 작업은 이런 느낌이다. 


1. Github 의 Pivotal 엔지니어링 블로그를 fork 해서 내 계정으로 당겨온다. 

2. 로컬 랩탑에 Hugo 를 구성한다. - brew 를 사용하면 매우 편리 

3. 로컬 랩탑에 vagrant 를 구성한다. - 로컬에 돌리려면 설치에 머리 싸매지 않아도 됨 

4. PWS 계정을 준비한다. 

5. Concourse 를 사용해 hugo 도구가 이상없이 페이지를 생성하는지 확인하고, 문제가 없다면 PWS 에 배포한다. (스테이징) 



백문이 불여일견, 백견이 불여일행이라. 이런 동작을 직접 구현하려면 아래의 도구에 대한 인식이 필요하겠다. 


1. vagrant 

2. docker 


Hugo 의 설치는 블로그에 매우 잘 설명이 되어 있으므로 넘어간다. git clone 따위 설명하지 않겠다. 

로컬에 Hugo 의 블로그를 구성하고 싶은 위치에 디렉토리를 만들고, github로 부터 가져온다. 직접 테마를 만들고 싶다면 그렇게 해도 된다. 


vagrant 환경 구성이 필요하다. 설치는 아래의 링크를 참조한다. 

https://www.vagrantup.com/docs/installation/ 


vagrant 설치가 완료되면, Concourse 를 사용할 디렉토리를 준비하고 아래의 링크에 소개된 대로 커맨드를 때리면 아주 쉽게 로컬에 준비된다. 만약 서비스의 용도로 설치를 원한다면 Bosh 를 사용할 필요가 있으므로, 이 부분이 궁금하다면 Pivotal 로 연락 주시길. 

https://concourse.ci/vagrant.html



준비 완료 메세지가 나오면, 이제 http://192.168.100.4:8080/ 주소를 사용하여 Concourse 에 접근이 가능하다. 처음 접근하면 뭐 아무것도 없고 썰렁하니 OS 이미지들만 나오는데, 바로 fly 라고 불리는 클라이언트 cli 도구를 다운 받아서 사용하라는 것이다. 이를 다운 받고, 압축을 해제한 후 원하는 디렉토리에 넣고 PATH 구성을 해 주면 되겠다. 여기에서 설명 되는 것 이상으로 Concourse 에 대한 사용법이 궁금하다면 아래 링크의 Tutorial 을 살펴보고 따라하다 보면 어느새 나도 전문가. 


https://github.com/starkandwayne/concourse-tutorial


주소로 접근하면 위와 같은 화면을 볼 수 있다. 현재로서는 아무런 파이프라인이 구성되지 않았기 때문이며, 본인이 사용하는 OS의 이미지를 클릭하여 클라이언트 도구를 다운로드 하면 되겠다. 


클라이언트 도구인 fly 의 PATH 구성을 완료 했다면, 아래의 커맨드를 참조하자. 


# 타겟 지정 

fly -t blog login -c 192.168.100.4:8080 


# 최초 파이프라인 구성 

# 파이프라인 파일에 대한 정보는 아래의 github 링크에서 pipeline 파일들을 참조 하면 되겠다. 

# https://github.com/younjinjeong/pipelines/tree/master/blog 


fly sp -t blog -c pipeline.yml -p yjeong-blog-test.yml -n -l ../../credentials.yml 


# 파이프라인 시작 

fly up -t blog -p yjeong-blog-test.yml 



그러고 나서 다시 192.168.100.4:8080 으로 접근하면 파이프라인이 생성된 것을 확인할 수 있다. 




github 링크의 파일 중 .sh 파일을 보면 git 를 구성하고 이후 hugo 를 설치한 다음 yjeong-blog-git 로 명명된 github 의 블로그 repository 에서 블로그를 가져다가 hugo 를 돌린다. 물론 여기에 Docker 를 직접 만들어 사용하면 각종 설치에 따른 불필요한 시간을 줄일 수 있을 것이다. 그리고 Pipeline repository 를 보면 알겠지만, 약 40여차례에 걸친 개인적 삽질 끝에 구성이 완료 되었음을 확인할 수 있을 것이다. 


추가적으로 위의 커맨드에 보면 credential.yml 파일이 있는데 이는 CloudFoundry 에 코드를 배포하기 위한 인증 정보가 담겨있다. 당연한 말이지만 이런 파일을 github 의 퍼블릭 레포에 올리면 문제가 될 것이므로 별도의 사설 repo 등에서 관리하는 것이 좋겠다. 


다른 파일은 제외하고, pipeline.yaml 파일을 살펴보자. 

https://github.com/younjinjeong/pipelines/blob/master/blog/pipeline.yml


---
resources:
- name: yjeong-blog-git
type: git
source:
uri: https://github.com/younjinjeong/yjeong.cfapps.io/
- name: yjeong-pipelines-git
type: git
source:
uri: https://github.com/younjinjeong/pipelines/
- name: yjeong-blog-staging
type: cf
source:
api: {{cf-api}}
username: {{cf-username}}
password: {{cf-password}}
organization: {{cf-organization}}
space: {{cf-space}}
skip_cert_check: false
jobs:
- name: yjeong-blog-test-app
public: true
serial: true
plan:
- get: yjeong-blog-git
trigger: true
- get: yjeong-pipelines-git
trigger: true
- task: yjeong-blog-test
file: yjeong-pipelines-git/blog/yjeong-blog-test.yml
- put: yjeong-blog-staging
params:
path: yjeong-blog-git/public/
manifest: yjeong-pipelines-git/blog/yjeong_blog_manifest.yml


보면 리소스를 정의하고, Jobs 에서 작업을 지정한다. 원하는 작업이 많을 수록 수많은 task 를 구성할 수 있으며, trigger 옵션은 git에 새로운 commit 이 발생한 경우 별도의 hook 이 없더라도 새롭게 업데이트된 코드를 가져온다. 그리고 중간에 yjeong-blog-staging 이라는 부분을 보면 소스를 별도의 방법으로 참조하고 있는데, 이는 fly 커맨드로 지정된 credential 파일에서 내용을 가져다 사용한다. 그리고 이 파일은 아래와 같이 생겨있다. 


cf-api: CF_ENDPOINT

cf-username: EMAIL

cf-password: PASSWD

cf-organization: ORG

cf-space: SPACE  


그리고 배포를 할때는 반드시 manifest 파일이 있어야 한다. 따라서 cf push 를 통해 이미 배포된 앱이라면 cf create-app-manifest 커맨드를 사용하여 다운로드 받을 수 있다. 


그리고 웹 UI를 통해 확인 할 수 있지만, 코드가 신규로 업데이트 되면 노란색으로 박스가 점멸된다. 테스트가 실패하면 빨강색으로 나오고, 해당 박스를 더블 클릭하면 어떤 작업이 수행 되었는지, 로그가 어떻게 나왔는지에 대해 작업 순서를 모두 확인이 가능하다. 




위의 경우는 "이전에 했던 테스트는 실패했고, 새로운 커밋이 들어와 새로운 테스트가 시작되었다" 라는 의미이다. 그리고 보면 yjeong-blog-staging 부분에 뻘건 한 줄이 가있는 것으로 보아, staging 배포에 실패한 것이다. 이런 경우 대부분은 credential 설정에 문제다. 




yjeong-blog-app-test 를 더블클릭하면 위와 같은 히스토리 화면이 나온다. 또는 현재 테스트가 진행되고 있는 경우라면 거의 실시간으로 테스트 아웃풋을 확인할 수 있다. 이는 Pipeline 에 지정된 Jobs 가 sequencial 하게 하나씩 수행 되었으며, 47번째 테스트는 모두 성공한 모습을 보여주고 있다. 여기에 각 작업 이름의 왼쪽 화살표를 클릭하면 작업의 디테일한 로그를 확인할 수 있다. 



위의 스크린샷은 간단한 테스트가 성공적으로 종료된 이후, PWS 에 성공적으로 블로그가 배포 되었음을 나타낸다. 그리고 이 블로그는 https://yjeong.cfapps.io 의 도메인으로 동작중이다. 



"에이~ 이게 뭐야 너무 간단한거 아니야" 라고 생각하실 수 있겠다. 그렇다. 이 데모를 위해 1일을 투자했다. 으헝 ㅠㅠ 

아래의 주소로 가시면 이것보다는 조금 더 현실세계에서 사용중인 복잡한 구성을 확인하실 수 있다. 


https://www.pivotaltracker.com/n/projects/956238

https://main.bosh-ci.cf-app.com/ 


위는 Bosh.io 프로젝트를 위해 Pivotal Tracker 에서 일을 정의하고, 이것들을 엔지니어들이 구현하여 bosh 용 concourse pipleline 을 구현한 모습니다. 




정리하면, 이런 구성은 만약 수많은 사람이 협업해야 하는 상태에서 Static 블로그, 또는 웹 페이지를 만들때 매우 효율적이다. 추가적으로 이것은 블로그만 하려고 구성한 것이 아니다. 이러한 파이프라인은 실제 개발에서 사용되는 것이며, 각각의 커밋 단위로 스테이징에 배포하는데 사용되는 기술이다. 따라서 각 팀별로 맡고있는 개발작업의 배포는 실제 이런 형태로 구성되고, 이렇게 모인 CI 들을 release 로 만들어 원하는 시점에 배포한다. 그리고 그 배포에 엄청나게 많은 코드가 사용되거나 사람이 무언가 손을 대는 작업은 없고, 자동으로 배포된다. 


한가지 더 언급하고 싶은것은, Docker file 을 원하는 대로 구성하여 Concourse 의 테스트에 사용할 수 있고, 자유도가 높은 스크립트를 사용하여 원하는 테스트 도구를 사용할 수도 있다. 이를테면 C나 Golang, python 등 다양한 언어로 개발된 애플리케이션 중 빌드가 필요한 것은 빌드의 단계를 구성하고, 이후 테스트를 수행하고, 그러고 문제가 없다면 스테이징에 안착시킬 수 있다는 의미다. 




Github 의 복사 붙여넣기 신공의 편의로 인해 무언가 좀 편리하게 포스팅한 느낌. 

다른거 없음. 백문이 불여일행. 


(younjin.jeong@gmail.com, 정윤진) 


Github with Xcode4

Techs

( younjin.jeong@gmail.com, 정윤진 )


인프라 기술자가 Xcode 를 사용한다는 것은 사실 엄청나게 흔한 일은 아니라고 생각한다. 나 역시도 맥북을 구매한지 벌써 2년이 넘어가지만, brew 를 사용한 맥용 패키지 관리에 필요하다는 이유로 Xcode 를 설치만 해 두고 있었다. 우분투라면 build-essential 패키지면 될 것을 어마어마한 덩치를 자랑하는 Xcode 를 왜 굳이 컴파일러와 분리해 두지 않았나 하는 생각이었달까. 


하지만 언제나 어플리케이션 디렉토리 한 구석에 자리잡은 망치는 vi 와 터미널이 슬슬 버거워 지는 '자동화 코드' 를 쓰기 시작하면서 점점 흥미를 일으켜 왔다. 뭐 물론 훨씬 가볍고 좋은 도구들이 많지만, 가끔씩 구동해서 텍스트를 넣어 보면 그 예쁘디 예쁜 syntax highlighting 이라던가, 자동 완성 등의 팬시한 모습이 '언젠간 쓰고 말꺼야' 하는 마음을 가지게 만들었다. 역시, 애플의 가장 큰 매력의 원천은 디자인으로 인한 호기심 유발, 그리고 사용해 보니 단순히 예쁜것이 아니라 기능도 좋다 라는 믿음이 발생하게끔 제품을 만드는 것이 아닌가 싶다. 



그대는 너무 아름답소



아무튼 최근의 대부분의 오픈소스 프로젝트들이 sourceforge 에서 github 로 옮겨 가면서, 이제 github 는 개발자건 관리자에게건 아주 중요한 업무의 장이 되어가고 있다. 우리 회사의 경우에도 github 에 private 계정을 만들어 사용중인데, 사내에 서버를 두고 별도로 관리 하는 것 보다 훨씬 낫다. 더군다나 웹 Front-end, Back-end 와 인프라 기술자가 각각 관장하는 코드를 하나의 저장소에서 작업하기 때문에, 또 나중에 장사 안되는 프로토타입은 open source 로 전향 할 가능성이 많기 때문에, 이 github 의 사용성은 우리에게는 축복이다. 


하여, Xcode 4 와 github 를 좀 같이 사용하면 참 좋겠다 싶은 생각에 그동안 미뤄왔던 Xcode 삽질을 오늘 시작 해 보았는데, 이 좋은 도구를 사용함에 있어 말도 안되는 부분에서 난관에 봉착하여 포스팅을 해 볼 까 한다. 그 난관이란 다름아닌 바로, 


"Xcode 의 Project 와 github 에서 받아온 repository 가 연동이 안된다." 


는 초딩스러운 문제다. 그렇다. 웃겨도 할 수 없다. 

대충 설명 하자면, 난관의 순서는 다음과 같았다. 


1. XCode 의 프로젝트는 반드시 신규 생성만 되며, 신규 생성할 때 "꼭" 디렉토리를 생성한다. 

2. XCode 에서 신규 프로젝트를 생성 할 때에는 기본으로 로컬 repository 를 생성한다. 

3. 따라서, 기존에 git clone 으로 받아온 working repository 를 직접 Xcode 에 추가 하려면 /PATH/TO/REPO/${PROJECT_NAME} 과 같은 거지 같은 형태가 된다. 

4. 해서 프로젝트를 먼저 생성 한 후에 .git 디렉토리를 init 시도를 해 보아도 연동이 되지 않았다. 



아무리 개발자가 아니라도 내 시스템 통밥이 몇년인데 이런거로 헤메자니 자괴감 마저 들었다는... 

일단 본인이 해결 한 방법은 다음과 같다. 



1. 원하는 디렉토리에 먼저 Xcode 로 File -> New -> Project 로 프로젝트를 생성한다. 본인의 경우 Xcode 에서 제공하는 컴파일러 및 라이브러리를 사용하지 않기 때문에 Empty 프로젝트를 선택 했다. 



음.. 이런 스크린샷까지 찍어버리다니!




2. Next 를 누르면, Project 이름을 묻는다. 아무리 테스트라도 나쁜 단어로 지지 하지 말자. 





3. 다음을 누르면 프로젝트가 사용 할 디렉토리를 선택하라고 한다. 



여기서 주의 할 것은, "Create local git repository for this project" 버튼의 체크를 해제 해야 한다는 것이다. 

이게 은근히 불편한 것이, Xcode 를 무시하고 터미널 작업과 같은 CLI 에 의존하는 경우 낭패를 보는 경우가 있다. 하지만 더 웃긴건, 어떤 부분에서는 CLI 로 처리를 해 주어야만 동작한다는 것. 



4. Create 버튼을 누르면 프로젝트는 생성이 완료된다. 해당 디렉토리로 가 보면, Xcode 에서 관리를 위한 무언가 디렉토리를 하나 생성해 두었다. 아마도 프로젝트 이름.xcodeproj 라는 이름의 디렉토리 일 것이다. 


기존에 있는 git repository 를 clone 해서 디렉토리를 사용 할 수 없기 때문에, git remote add origin 을 사용하여 코드를 가져온다. git 에 대해서는 별도의 설명은 하지 않는다. 한가지 더, 맥에서 git 를 설치하는 방법은 다루지 않는다. 궁금하신 분은 os x brew 로 구글링. 


Younjins-MacBook-Pro:Velox younjinjeong$ pwd
/Users/younjinjeong/Xcode/Velox
Younjins-MacBook-Pro:Velox younjinjeong$ git init 
Initialized empty Git repository in /Users/younjinjeong/Xcode/Velox/.git/
Younjins-MacBook-Pro:Velox younjinjeong$ git remote add origin https://github.com/XXXXXXXXXX/velox.git
Younjins-MacBook-Pro:Velox younjinjeong$ git pull 
remote: Counting objects: 251, done.
remote: Compressing objects: 100% (208/208), done.
remote: Total 251 (delta 38), reused 237 (delta 24)
Receiving objects: 100% (251/251), 622.49 KiB | 116 KiB/s, done.
Resolving deltas: 100% (38/38), done.
From https://github.com/XXXXXXXXXX/velox
 * [new branch]      master     -> origin/master
You asked me to pull without telling me which branch you
want to merge with, and 'branch.master.merge' in
your configuration file does not tell me, either. Please
specify which branch you want to use on the command line and
try again (e.g. 'git pull  ').
See git-pull(1) for details.

If you often merge with the same branch, you may want to
use something like the following in your configuration file:
    [branch "master"]
    remote = 
    merge = 

    [remote ""]
    url = 
    fetch = 

See git-config(1) for details.
Younjins-MacBook-Pro:Velox younjinjeong$ git branch -a 
  remotes/origin/master
Younjins-MacBook-Pro:Velox younjinjeong$ git checkout master 
Branch master set up to track remote branch master from origin.
Already on 'master'
Younjins-MacBook-Pro:Velox younjinjeong$ git branch -a 
* master
  remotes/origin/master
  remotes/origin/velox-Railway
Younjins-MacBook-Pro:Velox younjinjeong$ ls 
Velox.xcodeproj	app.js		dropbox.js	models		package.json	public		services	swauth		swift		views
Younjins-MacBook-Pro:Velox younjinjeong$ git pull 
Already up-to-date.


5. .gitignore 파일에 Xcode 에서 생성한 디렉토리를 추가한다. 


Younjins-MacBook-Pro:Velox younjinjeong$ echo "Velox.xcodeproj/*" >> .gitignore 




6. 이상 없이 모든게 완료 되었다면, 이제 다시 Xcode 로 돌아온다. Shift-CMD-2 를 누르면 Organizer 가 나타나는데, Repository Tab 에서 방금 작업한 디렉토리의 경로로 Repository 를 추가 해 준다. 



Type 이 Subversion 으로 걸리는 경우도 있는데, git repo 가 확실 하다면 git 로 선택 해 준다. 



7. Repository 의 추가가 완료 되면, 다음과 같은 화면을 볼 수 있다. Xcode 에서 Repository 를 체크하는 동안은 노랑색 아이콘이 표시되며, 확인이 완료되면 녹색으로 변경된다. 계속 주황색으로 머물러 있다면 경로나 github 의 계정을 체크 해 보도록 한다. 한가지 더, 간혹 Xcode 에서 github 사이트의 인증서가 확인이 안된다며 징징대는 경우가 있는데, 이때는 Certificate 버튼을 누르면 이 사이트는 항상 신뢰 와 비슷한 의미의 버튼을 찾아 볼 수 있다. 이 체크버튼을 활성화 하면 귀찮게 하지 않는다. 


일반적으로 github 를 커맨드 라인에서 사용할 때는 맥에 git 에 사용할 key chain 을 연동 할 수 있는데, 이는 매번 패스워드를 입력 할 필요가 없으므로 매우 유용하다. 단, key chain 에 시스템 부팅 후 처음 access 할 때에는 시스템의 패스워드를 묻는다. 






8. 이제 프로젝트 메인 화면으로 돌아오면, 처음 프로젝트를 생성 했을때와 마찬가지로 아무것도 보이지 않는다. 사실 일반적인 사용성을 가진다면 프로젝트의 디렉토리 정보를 가져다가 파일 및 디렉토리등으로 이루어진 코드들이 계층형으로 보여야 할 것 같은데, 아무것도 안보인다. 왼쪽 아래의 + 버튼을 이용하여 파일 및 디렉토리 추가를 선택하고, repository 내의 필요한 파일과 디렉토리를 모두 선택하여 추가 하도록 하자. 



하위의 디렉토리와 파일을 선택하여 모두 추가 하게 되면, 왼쪽의 프로젝트 브라우저에 계층형 구조로 추가된 디렉토리들이 리스팅된다. 이제 파일 중 하나를 살짝 변경하고 File -> Repository -> 탭으로 이동하면, 뭔가 Commit, Add, Push, Pull 과 같은 동작이 되어야 할 것 같은데, 아무것도 발생하지 않는다. 


만약 버튼이 활성화 되어 눌러보더라도, 다음과 같은 메세지가 발생한다. 



초저녁부터 자자는 얘기여 뭐여 - 타짜 광열씨 -



이것때문에 무던한 삽질을 했더랬다. 대체 왜 안되는지 모를 일이었다. 


결론은, Xcode 버그란다...


Xcode 한번 껐다 켜면 된단다.... 


윈도우냐... 



이 해법을 접하고 나서 살짝 멘붕이 올 뻔 했다. 하지만 역시 모든게 올바르게 동작하는 Xcode 는 세살배기 웃음마냥 사람 흐뭇하게 만드는 뭔가가 있다. 



이 화면은 commit 을 진행하면 나타나는데, 프로젝트 단위로 commit 이 필요한 파일의 목록을 보여준다. M 은 수정됨 의 의미이며, 신규 추가되는 경우에는 A 로 나타난다. 가운데의 코드는 당연히 diff 의 내용을 표시해 주는 것이며, 아래에는 commit 에 적용 될 메세지를 쓰는 부분이다. 


커밋하고 보면 Xcode 에서 이슈 관리 부분이 있는 것 같은데, Target 과 이슈 등을 적절히 사용하면 별다른 도구가 필요 없을 정도로 편리 할 것 같다. 


다 해 놓고 보니 별것도 아닌걸 가지고 한참을 헤멨다. 이영도님이 그랬던가. 혼돈의 신 헬카네스는 열쇠를 항상 가까운 곳에 숨겨둔다며... 


사실 그냥 몇 문장으로 그랬다 저랬다 해도 되는 내용이긴 하지만, 웬지 몇시간이나 날려버린게 서운해서 뻘포스팅 해 봤..;;; 


아참, 사용한 Xcode 버전은 4.4.1, 2012년 8월 7일 업데이트 버전인듯. 

이번 주말 및 다음주 초는 개 달려야지... 



덧1. 

왼쪽의 파일 브라우저와 같이 보이는 구조에서 실제 파일을 만들거나 하지 말아야 한다. 신규 생성하는 파일이 있다면 터미널에서 작업 해 주는 것이 안전하다. 이유인 즉슨, 실제 파일 및 디렉토리를 관리 하는 것이 아니라 논리적인 일종의 메타 브라우저인 것 같다. 이것때문에 또 한번 낭패를 볼 뻔. 


덧2. 

.gitignore 를 잘 설정 하지 않으면 엄한 파일들이 올라가므로 주의 할 것. 


( younjin.jeong@gmail.com, 정윤진 )