2015년 12월 22일 화요일

Dev & ops cooperation at Flickr: "10 deploys per day"

Flickr의 John Allspaw(Ops head)와 Paul Hammond(Dev head)가 
Velocity 2009년에서 발표한 영상

왜 DevOps를 해야 할까요?

DevOps는 소프트웨어 개발자와 정보 기술 전문가 간의 소통, 협업 및 통합을 강조하는 개발 방법론. 데브옵스는 소프트웨어 개발 조직과 운영 조직간의 상호 의존적 대응 이며 소프트웨어 제품과 서비스를 빠른 시간에 개발 및 배포하는 것을 목적으로 한다.

그럼, Amazon, Google, Netflix, Facebook, Twitter는 얼마나 자주 배포할까요?








2015년 12월 21일 월요일

DevOps 소프트웨어 딜리버리 하기



DevOps Process

Endless Possibilities: DevOps can create an infinite loop of release and feedback for all your code and deployment targets.




FaceBook, Flickr, Netflix, Etsy은 어떻게 DevOps를 할까요?

배포 주기
  • 매일 마이너 업데이트 
  • 메이저 업데이트 (매주 화요일 오후)

DeploymentAPipeline


출처: http://ieeexplore.ieee.org/xpl/article Details.js p?arnumbe r=644 9236


소스 버젼 관리
  • 모든 FB 개발자는 Single stable branch에서 작업
  • 따라서, long-lived branche들을 머징하는 데 시간 소비 하지 않도록 함 

Tools
  • 코드 리뷰: Phabricator (http://phabricator.org/)
  • 테스트 자동화: Watir (http://watir.com/)
  • 테스트 자동화: Selenium (https://github.com/seleniumhq/selenium)
  • 성능 테스트: Perflab 

커뮤니케이션
  • 자체 IRC서버로 배포할 때 관련자들 다같이 IRC로 커뮤니케이션 (평균 700명)
  • 개발자가 몇 분 내로 답변하지 않을 때는 해당 개발자 개발한 건 빼고 배포 

서비스 모니터링
  • 배포 이후에 트래픽의 변화, 자원 사용량, 프로덕션 환경의 각각 세그먼트들 등
  • 심지어 Facebook에 대한 트윗들까지 모니터링함

Global Public Internet Companies, Ranked by Market Capitalizatiion

자료: http://www.kpcb.com





2015년 12월 18일 금요일

Supplier의 ISO 26262 대응을 위한 개발 환경 구축 사례




철도분야 SW 품질보증 실현 방안

최근 첨단 전자 산업의 발전과 함께 IT와 제조업 간의 융합이 가속화 되면서 철도 분야에서도 하드웨어에 소프트웨어가 결합된 철도시스템 사용이 증가하고 있다. 철도는 신속한 이동과 안전한 교통수단이지만 열차 사고 발생 시 자칫 대형사고로 인한 많은 인명 사상에 이를 수 있는 교통수단이기 때문에 안전에 대한 요구사항이 대단히 높다. 지난 5월, 국내에서 250여 명이 중경상 피해를 입은 지하철 2호선 추돌사고도 신호 시스템의 오류에 의한 것으로 밝혀진 바 있다. 이와 같은 소프트웨어 결함은 심각한 문제를 일으킬 소지가 있기 때문에 오늘날의 SW 품질은 과거와는 비교할 수 없을 정도로 중요한 영역이다.
  1. 철도분야 안전표준 -  IEC 62278/ IEC 62425/ IEC 62279/ IEC 62280 
  2. 안전무결성수준(SIL)의 설정
  3. 철도분야 SW 수명주기
  4. 철도분야 SW 품질보증
  5. (주) 세화 SW품질보증 사례