Git을 이용한 협업 워크플로우 배우기

today 2016-06-20 face Posted by appkr turned_in Learn & Think forum 0

이 문서는 Atlassian社에서 쓴 ‘Getting Git Right’ 튜토리얼 중 ‘Comparing Workflows’라는 글을 한글로 번역한 것이다. 이 글에서는 총 네 개의 워크플로우를 소개한다.

  1. Centralized Workflow
  2. Feature Branch Workflow
  3. Gitflow Workflow
  4. Forking Workflow

이 글에서는 여러 엔터프라이즈 개발팀을 조사하여 정리한 대표적인 Git 협업 워크플로우를 소개한다. 여기서 제시하는 워크플로우들은 엄격한 규칙이라기 보다, 여러 분들의 상황에 적합한 워크플로우를 선택하기 위한 일종의 가이드로 이해해 주면 좋겠다.

dotfiles 만들기

today 2016-05-22 face Posted by appkr turned_in Work & Play forum 0

dotfiles는 개발자들이 사용하는 .bash_profile, .ssh 등 dot(.)으로 시작하는 파일 또는 디렉터리의 모음이다. dotfiles는 콘솔용 바이너리(e.g. gcc), 라이브러리, 애플리케이션의 설치 뿐만아니라, 그들의 설정을 잘 저장해 두었다가 컴퓨터를 빠르게 재구성하기 위한 워크플로우다.

dotfiles를 구성해두면, 예를 들어 gulp, git-flow, sublime-text3, google-chrome 등, 내가 사용하는 애플리케이션 및 개발 도구의 목록과 설정을 저장해 두었다가 다른 컴퓨터 또는 새 운영체제에서 애플리케이션 설치뿐만아니라, 심지어 코드 에디터의 설정까지도 다른/이전 컴퓨터와 똑같이 ‘바로’ 사용할 수 있다.

이번에 맥을 밀고 다시 설치할 일이 있어서, 오랫 동안 미루어 두었던 dotfiles를 시전했다. 필자도 이번 경험을 통해 알게된 사실인데, 운영체제를 다시 설치할 때만 dotfiles를 만들거나 적용할 수 있다고 생각하지만, 사실이 아니다. dotfiles는 운영체제를 다시 설치하지 않더라도 언제든 준비할 수 있다.

유명한 dotfiles들을 검토했는데 정석은 없더라. 쉘 스크립트만 이용한 사람, 주제별로 디렉터리를 분리한 사람, 다른 툴을 이용하는 사람, 운영체제도 제각각이더라. 이 포스트에서는 맥 운영체제 기준으로 dotfiles를 준비하는 방법을 공유한다. 다음 도구들을 이용한다. 앞서 말했듯이 정석은 없으므로 꼭 이렇게 할 필요는 없다.

  1. Homebrew
  2. Homebrew Bundler
  3. Mackup
  4. .osx
  5. Shell Script

시전하는 과정에서 운영체제를 두 번 설치해 봤는데, 이 정도 경험으로는 다른 이의 맥에서도 동작하는 은총알 dotfiles How-to를 쓰기에는 무리다. 어쨌든 진리는 ‘평상시에 dotfiles를 준비해 두면, 불의의 사고에 빠르게 대처할 수 있다’라는 점이다.

서비스 URL의 중요성 및 변경의 비용

today 2016-05-18 face Posted by appkr turned_in Work & Play forum 0

웹 서비스를 하다 보면 마이그레이션을 해야 할 때가 반드시 찾아 온다. 트래픽 양이 변해서 더 큰 또는 작은 서버로 이전한다거나, 다른 프로그래밍 언어 또는 다른 프레임워크로 갈아타야 한다거나..

나에게도 찾아 왔다. 라라벨 온라인 강좌의 라이브 데모 사이트를 AWS(Amazon Web Service)에서 서비스하고 있었는데, 요금이 꽤 나와서 Github Page로 옮겼다. 회원 가입등 서버가 필요한 동적 기능은 버리고, HTML로 강좌만 서비스하는 정적 웹 페이지로 바꾸었다. 이 과정에서 어쩔 수 없이 URL을 변경했다.

변경 전 변경 후
/lessons/01-welcome.md /lessons/01-welcome.html

Jigsaw라고 하는 정적 사이트 빌더를 이용했는데, 로컬 컴퓨터에서 마크다운으로 작성한 강좌를 정적 HTML 파일로 전부 트랜스파일한 다음, Github Page에 올리는 방식이다. Jekyll을 이용한 이 블로그와 빌드 도구만 다를 뿐 똑같은 방식이다.

AWS 라이브 데모를 닫은 지 2주일 정도됐다. 사용자가 구글 검색 엔진을 통해 들어온다면, 기존의 URL은 당연히 열리지 않는 황당한 경험을 하게 된다. 구글로부터 최근에 404 응답이 많아졌다는 메일을 받았지만, 아무 생각없이 그냥 무시했었다. 커뮤니티에서 같이 활동을 하는 김종운님과 어제 대화를 나누기 전까지는 말이다.

URL이 바꼈던데, 그간에 쌓아 놓은 구글 검색 순위가 아깝지 않으세요?

김종운님

Google Search Console로 확인해 보니 다행히 그간에 검색 엔진을 통해 들어온 사용자는 그리 많지 않았고, 순위도 그리 높지 않았을 것이라 생각한다. 그러나, 2 주간 불편을 겪었을, 또 앞으로 불편을 겪을 수도 있는 사용자를 생각하면 고치지 않을 수 없었다.

이 포스트는 다음 내용을 다룬다. SEO(Search Engine Optimization, 검색 엔진 최적화)라는 관점에서 공통점이 있다.

  1. Github Page에서 URL Redirect를 구현한 로그
  2. SEO 관점에서 URL의 중요성 및 일반적인 URL Rewrite 방법

Git Flow

today 2016-05-04 face Posted by appkr turned_in Work & Play forum 0

Git Flow 는 Vincent Driessen이 제안한 깃 브랜칭 전략을 실행할 수 있도록 돕는 Git 확장 프로그램이다. 이 전략은 masterdevelop을 각각 배포 및 개발 브랜치로 사용하면서, feature, release, hotfix 등을 위한 임시 브랜치를 사용한다.

아래 그림은 Git을 소개하는 웹 문서나 서적에서 한번은 본 그림일 것이다. 많은 개발자들이 이 전략을 모범 사례로 인식하고, 따르고 있다는 방증이다.

이 포스트는 Git Flow의 기본적인 사용법을 담고 있다. 사실 여기 수록한 내용이 전부인 듯 하다.

소프트웨어 개발 비용

today 2016-04-27 face Posted by appkr turned_in Learn & Think forum 0

소프트웨어 개발 비용은 ‘돈’ 보다는 ‘시간’의 의미가 더 크다. 개발 비용은 크게 보면 다음 세 가지로 구분할 수 있다.

  1. 도입 비용
  2. 수정 비용
  3. 소유 비용

각 비용을 적절히 배분해야 전체 비용이 줄어든다. 가령, 성공을 확신할 수 없는 새 제품이나 서비스를 개발하는데, 오버 엔지니어링해서 많은 도입 비용을 쓰는 사례를 들 수 있다. 또는 도입 비용을 너무 싸게 예측해서 급히 개발했는데, 시장 반응이 좋은 상황이다. 분명 개발의 훌륭함보다는 아이템의 승리다. 수정해야하는데, 팀의 빨리빨리 문화에 회의를 느낀 초기 개발자는 회사를 떠났고, 스파게티 코드만 남아 누구도 손댈 수 없는 사례도 생각해 볼 수 있다. 내 일천한 경험에 비추어 보면 이런 코드로 램프 업한 사업은 곧 망하더라(대규모 투자를 받아 팀을 리빌드한 경우는 제외).

keyboard_arrow_up