바이든 대통령님 초거대기업 MS의 자회사 Github의 횡포를 막아주세요.

바이든 대통령님, 안녕하십니까.

저는 빌드배포산업 협회원이며 해당 산업에 종사하고 있는 영세 자영업자입니다.

근래 거대기업 MS가 막대한 자본력을 바탕으로 개발자의 성지인 Github서비스를 인수하는 사태가 발생하였읍니다. 오픈소스 정신으로 무장한 개발자들의 공동체가 거대 자본의 발밑에 들어가 버린 사건으로 저와 저희 협회 그리고 전세계 개발자들이 많은 걱정을 하였읍니다. 하지만 한동안 MS는 별다른 행보를 취하지 않은 상태로 Github를 기존처럼 운영하는 척을 하였읍니다. 하지만 Github Action이라는 기능이 추가되면서 사건은 급전직하 되어 버리고 말았읍니다.

Github Action이라는 기능은 기존에 기술자들이 배쉬 쉘스크립트를 활용해 한줄한줄씩 한달에 거쳐 만들던 빌드배포 기능을 와이엠엘 형태로 선언적으로 쉽게 만들수 있게 해 버리면서 많은 빌드배포 개발자들의 일자리를 빼앗아 가고 있읍니다. 이는 AI보다 더욱 목전에 닥친 일자리 위협으로 저희 빌드배포 개발자들은 생명의 위기를 느끼고 있는 상태입니다.
 또한 비슷한 혁신을 꿈꾸며 사업을 키워나가던 Travis, CircleCI 등의 회사는 꿈을 펴기도 전에 위기에 빠져 버렸습니다. Github Action은 기존 Travis, CircleCI가 개발한 와이엠엘형태 선언방식을 그대로 따라한 아류작이지만 MS의 초거대자본을 등에업은 Github의 독점력을 바탕으로 급격하게 시장을 탈취 해 가고 있읍니다. 기존 서비스를 모방했지만 선언방식을 조금 더 쉽게 개선하고 다양한 샘플과 풍부한 도큐먼트를 제공하여 기존 업체들은 경쟁이 불가능하도록 전방위 압박을 받고 있습니다. 고사위기에 처한 영세 스타트업과 영구적 실업위기에 빠진 빌드배포개발자들은 한숨속에 잠을 못 이루고 있읍니다.

 빌드배포산업은 소프트웨어 뿌리산업으로 웹개발 업계를 지탱하고 있읍니다. 저희가 무너지는 것은 괜찮지만 저희 업계가 무너지는 것은 소프트웨어 업계의 몰락을 뜻합니다. 저희 협회원 뿐 아니라 인접산업군 그리고 그 가족들과 그 친척들과 그 친구들까지 10억명의 생계와 친목이 걸려 있는 중대한 사아님을 말씀 드립니다.

빌드배포산업 종사자의 한 명으로써
저희 산업협회의 입장을 전달 드리겠읍니다.

첫째, 빌드배포산업협회는 해당 산업을 중소기업 적합업종으로 지정하여 자본금 1000억원 이상의 업체들이 진출하지 못하게 막아 줄 것을 요구하는 바입니다. 이는 저희 협회뿐만 아니라 인접산업에도 해당되는 문제로 MS는 운영체제와 클라우드 이외의 산업에 진출하는 것을 영구적으로 막는 규정을 미국 연방의 재수정헌법에 명시해 주실 것을 요청 드립니다.
둘째, 저희 빌드배포산업협회는 MS 윈도우즈엑스피의 소스공개를 요청하는 바입니다. MS는 해당 오에스의 업데이트를 임의로 중지시키고 업데이트를 해 주지 않아 사용자들의 오에스 선택권을 심각하게 침해하고 있는 상태입니다. 윈도우즈10을 강매하는 것과 동일한 행위로 엠에스의 독점적 영향력을 통한 시장 교란행위에 해당합니다. 윈도우즈 엑스피의 소스코드를 공개하여 사용자들이 스스로 보안문제를 해결하면서 사용할 수 있게 만들어 주실 것을 요청 드립니다.

해당 요구사항이 받아들여 지지 않을 경우 저희는 협회 차원에서 MS불매운동과 더불어 바이든 대통령 탄핵 평화촛불 네트워크를 가동시키기로 내부적으로 협의된 바 있읍니다.

실력행사를 할 일이 없길 바라며

서울에서 빌드배포협회 배상

DevOps 환경별 구분

개발 및 배포 단계

  • Dev,Devel,Development – 개발자 개발중
  • QA,Alpha – QA자 QA중
  • PreProduction,Staging – 라이브자 라이브전
  • Live,Real,Production – 라이브자 라이브중

서버의 성격/위치

  • 개발자 본인 장비 – 개인용
  • 공동 관리하는 서버 – 사무실 서버,IDC,Cloud
  • 서비스 서버 – IDC,Cloud

세분화된 개발환경 구분

  • Dev Local Mock – 한개 서비스에서 연동서비스는 Mock 데이터
  • Dev Local/Remote Integration – 개발용 인프라에 연동서비스 함께
  • Test Remote Feature – 특정 기능 요소별로 테스트가능한 환경
  • Test Remote QA – QA 및 업무담당자 테스트환경 (수동 및 자동)
  • Live Remote Pre-Production – Production의 데이터까지 복제해서 만든 환경에 배포 결제 등 외부서비스 Real 연동
  • Live Remote Production – 실제 서비스 환경

테스트 종류

  • Manual Test
  • Unit Test
    • Mock API
    • Mock Data
  • Dev Integration Test
    • Real API
    • Seed Data
  • Live Integration Test
    • Real API
    • Real Data
  • Health Check

테스트 방법

  • Manual
  • Script

단계 구분

  1. Dev
    1. Local Dev Unit Test(Automatic)
    2. Local Dev Integration Test(Automatic)
    3. Git push – dev
    4. CI Build Unit Test
    5. Remote Dev Integration Test(Manual)
  2. Test
    1. Feature Test
    2. QA Test
    3. Success/Fail
  3. Live
    1. Pre-Production Test
    2. Production

현재까지의 순서

DevOps – CI/CD 시스템 구축

시스템 구성

  • 빌드, 컴파일, 유닛테스트
  • 배포 – 테스트환경 – 버전별로 분기해서 동작
    ex) ver 20171021, ver 20171106

두 버전이 동시에 돌아갈 수 있음.

latest사용 또는 특정버전 사용

  • health check

시나리오 테스트

Real서버배포 – aws, gcp 등 cloud환경 배포시 배포 완료 후 ssh daemon 종료. 접속불가. immutable. 삭제만 가능.

 

참고글

https://cloud.google.com/container-registry/

https://cloud.google.com/container-registry/docs/continuous-delivery

https://cloud.google.com/solutions/spinnaker-on-compute-engine

https://martinfowler.com/articles/continuousIntegration.html
https://martinfowler.com/bliki/ContinuousDelivery.html

요약정리는 읽어본 후

추가 다른글
https://trello.com/c/rOmLEI0u/9-%EB%A7%88%ED%8B%B4-%ED%8C%8C%EC%9A%B8%EB%9F%AC%EC%9D%98-is-design-dead

http://blog.naver.com/j6040148/120015111138

https://martinfowler.com/articles/designDead.html

https://www.gocd.org/2017/07/10/gocd-vs-spinnaker/

MSA – 의존성 관리 방법

Global Dependency Dictionary System 정도로 불러도 되려나

MSA로 서비스를 구성할 때 발생하는 문제가

어떤 서비스를 Deprecated를 시켰을 때 이전 버전을 언제까지 유지시켜야 할지가 애매하다.

즉각적으로?

한달이상 호출이 없을 때?

모니터링 툴 돌리다가 수동으로?

그냥 소스코드 내부에 /v1 /v2 /v20171001 같은식으로 계속 유지시켜버릴까?

이런 방법은 다 확살하지 않거나 관리가 불편하거나 다양한 문제가 있다.

디비를 변경해야 하는경우에 버전업을 할 때 오류발생 가능성도 있고

 

배포시에 사전을 만들고 의존성을 갖는 프로젝트간의 관계를 가지고 있는게 좋을 것 같다.

일반적인 형태의 라이브러리나 프레임워크로 만들기는 힘들 것 같고

규칙성을 갖게 버저닝을 하고 배포를 해야할 것 같다.

v{메인버전_호환안될수있음}-버그픽스

v1_20171001-1

v1_20171001-2

버전 표기방식으로 흔히 쓰는건 이정도 아닌가

 

버그픽스버전의 경우

3번째칸은 변경되도 호환성에 문제가 없어야하고 1,2번칸이 변경될 경우 호환이 안될 가능성이 생기는걸로

버그픽스 버전이 배포되는 경우 유닛테스트 실행. 이상이 없어야만 배포허용.

 

버전업이 되는 경우

배포시 의존성을 갖는 서비스의 관리자에게 알림이 가고

유닛테스트가 실행. 오류가 나면 오류알림(해당서비스와 의존성을 갖는 서비스의 담당자)

의존성을 갖는 서비스의 담당자는 일정시일(1개월?)이내에 업데이트 권장

긴급수정 사항은 바로 업데이트

 

이 경우 배포툴에 각 개발자의 정보가 담겨있어야한다.