tag:blogger.com,1999:blog-6060875800282210631.post4677031458783269269..comments2023-11-08T05:29:09.590+09:00Comments on All of Software: 소프트웨어 프로젝트에서 빌드를 어떻게 하시나요?전규현http://www.blogger.com/profile/02706025917864233238noreply@blogger.comBlogger10125tag:blogger.com,1999:blog-6060875800282210631.post-3463779368684465102019-01-17T11:50:25.963+09:002019-01-17T11:50:25.963+09:00빌드에 대해 중요성을 알게되었네요.감사합니다.빌드에 대해 중요성을 알게되었네요.감사합니다.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-6060875800282210631.post-39564235286498296752008-11-10T18:02:41.000+09:002008-11-10T18:02:41.000+09:00지난 주말에 CruiseControl.NET을 이용하여 빌드환경을 구축했는데 오늘 이 포스...지난 주말에 CruiseControl.NET을 이용하여 빌드환경을 구축했는데 오늘 이 포스트를 보니 딱 뭔가 박자가 맞는거 같은 느낌이...^^<br>하지만, 뒤에 붙을 것들(자동화 테스트, 배포환경등)이 없는 상태에서는 좀 썰렁하네요.<br>주변에 자랑했다가 "왜 이렇게 (쓸데없이) 빌드를 자주해요?" 뭐 이런 소리도 좀 듣구요 ^^;헝그리맨http://www.codereview.co.krnoreply@blogger.comtag:blogger.com,1999:blog-6060875800282210631.post-65590940189336787202008-11-10T18:42:27.000+09:002008-11-10T18:42:27.000+09:00헝그리맨님 반갑습니다.다른 사람들도 헝그리맨님같이 좋은 툴이나 프로세스를 도입해도 이해를 ...헝그리맨님 반갑습니다.<br>다른 사람들도 헝그리맨님같이 좋은 툴이나 프로세스를 도입해도 이해를 잘 못하는 사람들의 반대에 많이 부딪히곤 합니다. 따라서 남을 설득할 수 있는 지식도 있어야 지요. 그렇다고 남과 부딪히지는 마세요.<br>CruiseControl은 CI솔루션 중의 하나죠. 소프트웨어는 구현 초기부터 지속적인 빌드가 되어야 하고 자동화 되어야 하는 것을 많은 사람들이 모르죠.<br>힘네시고요. 앞으로도 할게 많습니다. ^^<br>궁금하신 것이 있으면 언제든지 찾아오세요.Ray♫http://softwaredev.tistory.comnoreply@blogger.comtag:blogger.com,1999:blog-6060875800282210631.post-34710740651545446052008-11-13T07:46:27.000+09:002008-11-13T07:46:27.000+09:00좋은글 잘봤습니다.좋은글 잘봤습니다.yagurhttp://yagur.impon.netnoreply@blogger.comtag:blogger.com,1999:blog-6060875800282210631.post-59520505973835028452008-11-24T23:48:03.000+09:002008-11-24T23:48:03.000+09:00yagur님 반갑습니다.종종 뵈요.yagur님 반갑습니다.<br>종종 뵈요.Ray♫http://softwaredev.tistory.comnoreply@blogger.comtag:blogger.com,1999:blog-6060875800282210631.post-64474589795749677242008-11-24T17:58:14.000+09:002008-11-24T17:58:14.000+09:00헉.. 저희는 그냥 막 빌드를 해버렸는데.. -_-;;;이런식으로는 전혀 생각을 못해본것 ...헉.. 저희는 그냥 막 빌드를 해버렸는데.. -_-;;;<br>이런식으로는 전혀 생각을 못해본것 같습니다.. ㅠㅠkkommyhttp://kkommy.comnoreply@blogger.comtag:blogger.com,1999:blog-6060875800282210631.post-71995298515597081882008-11-24T23:48:45.000+09:002008-11-24T23:48:45.000+09:00빌드의 중요성을 먼저 아는게 중요한 것 같습니다.그리고 자동화된 빌드는 생산성을 대단히 높...빌드의 중요성을 먼저 아는게 중요한 것 같습니다.<br>그리고 자동화된 빌드는 생산성을 대단히 높여줍니다. 하나하나 시도해보세요.<br>감사합니다.Ray♫http://softwaredev.tistory.comnoreply@blogger.comtag:blogger.com,1999:blog-6060875800282210631.post-55897650779184827102011-05-06T08:31:40.000+09:002011-05-06T08:31:40.000+09:00안녕하세요.최근이 이런 멋진 블로그가 있는걸 찾아서 정독 중에 있습니다.최근 프로젝트 진행...안녕하세요.<br>최근이 이런 멋진 블로그가 있는걸 찾아서 정독 중에 있습니다.<br><br>최근 프로젝트 진행 중에 본문의 Daily Build라는 것 때문에 엄청 고생한 적이 있어 질문을 드립니다.<br><br>질문1. Daily Build라는 것을 통해 검증하는 범위가 어디까지인지 궁급합니다.<br><br>저는 핸드폰 제작 회사의 SW 부분에서 일을 하고 있는데요,<br>해당 SW는 핸드폰이라는 HW에 인스톨되어 동작시키기 전까진 정상동작 여부를 판단하기가 어렵습니다.<br><br>지난번 프로젝트부터 Daily Build라는 이름 하에 매일 Build를 하고 Bug를 찾아내는데요.<br>일단 문제로 대두된 것이<br>1. 개발 진행 중이라 완성이 안된 Function에 대한 테스트를 진행해서 Bug 아닌 Bug를 찾아서<br>담당자에게 메일 리포팅함으로써 이유없는 업무 로딩 생성<br>2. 이건 저희 회사의 문제일 수 있는데... 경험 없는 개발자들이 프로젝트에 대거 투입되면서<br>build error 대량 발생으로 수많은 재 build 상황 발생 -> 타 개발자도 모두 대기<br>이전의 Event Base로 Build를 하는 식으로 진행을 했을 때는<br>경험이 부족한 개발자가 프로젝트에 참여를 해도 상대적으로<br>그 사람으로 인해 발생하는 오버헤드가 크지 않았습니다.<br><br>암튼 개인적으로 build와 bug test는 분리되어야 한다고 생각합니다만,<br>한편 생각하면 build 해서 error 안나는 수준까지만 검증할꺼면,<br>왜 daily build를 한까 하는 의문도 들고 <br>(build Error를 지속적으로 만드는 개발자와 같이 일하는 것도 고역이긴 합니다만)<br>그렇다고 bug 테스트를 병행하면 시간이 너무 많이 들고...<br>흠.. 개발자는 그나마 스펙(표준규격, 사업자 요구사항, etc...)을 아는데(모르는 사람도 많아졌...)<br>테스터는 그걸 모르는 경우가 많은 것도 문제이군요....생각나무noreply@blogger.comtag:blogger.com,1999:blog-6060875800282210631.post-89665471390742946992011-05-07T09:02:09.000+09:002011-05-07T09:02:09.000+09:00안녕하세요. 생각나무님요즘 Daily Build에 대해서 오해를 하고 있는 사람들을 매우 ...안녕하세요. 생각나무님<br><br>요즘 Daily Build에 대해서 오해를 하고 있는 사람들을 매우 자주 만납니다. <br><br>Daily Build의 원래 목적은 Broken Tree를 방지하는 겁니다. 즉, 프로젝트가 매일 빌드 가능한 상태를 유지하기 위한 겁니다. 여기에 추가로 Smoke Test, 정적테스트를 하는 경우도 있기는 하지만 이는 모두 자동화 된 것이고 인력을 투입해서 테스트를 하지는 않습니다.<br><br>테스트는 별도의 스케쥴을 정해서 진행합니다. 추가로 말씀을 드리면 Daily Build는 설계가 끝나고 구현이 시작되는 첫째날부터 가능해야 합니다. 이게 안되면 설계가 안된 겁니다.<br><br>테스터가 스펙을 모르는 것은 스펙을 적지 않았거나 부실하게 적었기 때문입니다. 그리고 테스터와 리뷰도 안된 겁니다. <br><br>스펙을 제대로 적지 않는 것이 프로젝트가 엉망으로 되는 가장 큰 이유입니다.전규현http://allofsoftware.netnoreply@blogger.comtag:blogger.com,1999:blog-6060875800282210631.post-1889182065021925032008-11-11T16:06:59.000+09:002008-11-11T16:06:59.000+09:00현재 진행중인 프로젝트가 수동빌드를 하고 있는데, 정말 고민이 많은 부분이다. 소스 및 버...현재 진행중인 프로젝트가 수동빌드를 하고 있는데, 정말 고민이 많은 부분이다. 소스 및 버전관리를 SVN를 통해 진행중인데, Repository에 업데이트된 소스를 자동빌드후 서비스 디렉토리로 이동하는 부분에 대해선 아직 답을 찾지 못하고 있다. 레이의 소프트웨어 개발 토론 팀블로그에서 언급한대로 커멘드창에서 특정 명령어의 타이핑만으로 현재 버전이 자동으로 적용되어야 한다는 점엔 동의한다. 문제는 어떻게 그 부분을 구현하느냐다. 단순한 버그 수정 및..이끌림...그리고 중독http://archie.tistory.com/entry/개발-프로젝트-자동빌드noreply@blogger.com