• [2018] Print모듈 자동업데이트 시스템 구축

    개발배경

    기존 윈도우 클라이언트 응용프로그램에서 웹브라우저 환경의 제품으로 전환됨에따라, 라이브러리 형태로 제공되던 인쇄모듈을 독립적인 실행이 가능한 형태로 개발할 필요가 생겼습니다. 또한 패키징 및 배포, 업데이트까지 기능을 확장시켜 기능을 추가될때마다 고객이 직접 재설치를 하지 않고, 자연스럽게 사용할수 있도록 개선할 필요가 있었습니다. 


    프로젝트 설명
    - NSIS를 통한 설치파일 제작(인스톨 쉴드 라이센스도 있지만 최대한 가볍게 만들기 위해)
    - 로컬 웹서버(https)를 통한 설치 유뮤 체크 및 exe 실행 
    - 버전 정보에 따라 자동 업데이트 or 재설치 
    - API를 통한 데이터 및 서식 다운로드 및 인쇄 다이얼로그 실행


    상세 업데이트 방법
    - 웹서버에서 서비스 구현없이, 단순 파일서버로만 이용
    - 로컬의 버전파일(xml), 서버의 버전파일(xml) 비교
    - 서버의 버전이 최신일 경우 서버 버전파일에 입력된 파일경로를 호출해서 파일 다운로드
      주버전 부버전에 따른 파일 타입별 다운로드(압축된 파일형태 or 인스톨파일exe) 및 실행
    - 파일유효성 검증 X


    위와 같은 방법으로 구현한 이유 
    - 이미 안정화 단계를 넘은 컴포넌트라서 기능 추가 및 수정에 대한 이슈사항이 적을거라 판단해서
    - 항상 exe 버전을 배포시킨다 하더라도, 서버 트래픽을 고려할정도의 사이즈가 아니며 호출횟수가 많지 않음.
    - 최대한 빠르고 간단하게 만들기 위해서


    담당업무

    - 단독 실행모드 개발, 업데이트 시스템 개발(내부, 외부), NSIS 패키징 개발


    사용기술
    - .Net Framework, NSIS


    개발이슈사항
    - 다국어 처리를 위해 사용되는 모든 텍스트를 별도의 xml 파일로 구성
    - 내부 테스트를 위한 업데이트 모드 분리




    몇년간 유지보수 후 느낀점(2022..)
    - 2~3달에 한번씩 수정될때마다 업데이트 버전관리가 헷깔림(오히려 애매하게 띄엄띄엄 들어와서 더 힘듬)
    - 내부 테스트를 거쳐서 배포하더라도 항상 긴장하게 됨.(잘못되면 버전올려서 바로 이전파일로 롤백시켜야 하기 때문..)
    - 빌드 후 배포까지 너무 귀찮고, 다른사람이 하기 힘듬
      (빌드 -> 서명 -> 이전 배포된 파일 체크 -> 배포형식 결정(exe, zip) -> 설치용 NSIS 패키징 -> 패키징 파일 서명 -> 파일서버에 올릴 폴더 구조생성 -> 폐쇠망용 구조 별도 생성)

    - 빌드 이후 작업을 한번에 자동으로 하는 프로젝트 개발
    (업데이트 할 파일을 등록하면 자동으로 현재 배포된 버전 조회해서 다음버전으로 셋팅시키고 패키징 및 배포용 파일(단순 업로드만 하면 되는 파일) 생성)

    - 파일 버전 및 업데이트 버전을 깃으로 연동시킬까 고민중
    빌드 -> 깃에 파일 추가 -> 웹서비스를 추가하여 깃의 목록을 다운받고 선택한 커밋에대해 위 자동화 작업 진행 -> 타겟서버에 배포 -> 활성화 
    롤백또한 특정 버전 커밋 선택후에 빌드 배포 

  • Copyright @ 2013 Timeline.