임베디드 소프트웨어 용 (CI) 서버

Question

임베디드 시스템 용 빌드 서버 사용 경험을 묻고 싶습니다. 무엇을 사용하고 있습니까? 있다면 무엇이 좋고 나쁜 편입니까?

우리는 주로 운영 체제가없는 마이크로 컨트롤러 용으로 개발하고 있습니다.

지금은 젠킨스를 사용하려고하는데 빌드가 실행 중입니다. 하지만 프로젝트 구조에 문제가 있습니다. 모든 플러그인을 작동 시키려면 평면 구조가 필요합니다. 그러나 우리는 병행하여 개발 된 프로젝트가 거의 없으며 직업 뷰가 엉망이되기 시작합니다. 폴더를 시도했지만 일부 플러그인이 작동하지 않습니다.

파이프 라인을 만들고 싶습니다. 파이프 라인은 순차적으로 실행되지만 내부에는 병렬 작업이 있습니다. 예. 커밋 단계 : 컴파일, 보풀 검사, 스타일 검사, 단위 테스트. 모두 병렬로 실행할 수 있으며 모두 성공하면 다음 단계가 실행됩니다.

• 빌드 파이프 라인 지원
LDAP 기반으로
• 사용자 인증
• 병렬 작업 실행
• 계층 프로젝트 (프로젝트/구성 그룹)
: 나는이 순간에 빌드 서버에서 필요한 것은
• xUnit, Lint, 컴파일러 경고, Robot 프레임 워크에서보고합니다.

• 슬레이브/에이전트 지원, 노예

• 권한 태그는 LDAP 그룹에 내가 어떤 제안, 오픈 소스와 상용 오픈하고있어 그룹/프로젝트

당

권한을 기반으로. 나는 비디오에서 대나무를보고 있었는데 매우 멋져 보였지만 나는 아직 시도하지 않았다.

우리는 서로 다른 프로젝트를 개발중인 두 개의 개발 팀이 있습니다. 그룹을위한 팀 및 권한으로 프로젝트를 그룹화하는 것이 좋을 수 있습니다. 한 그룹의 구성원은 다른 그룹의 구성원을 수정하면 안됩니다. 그러나 "가지고 있어야하는 것"보다 "가지고있는 것이 좋다".

인 TeamCity

나는 인 TeamCity를 사용했습니다. 건물 빌드 파이프 라인은 젠킨스 (Jenkins)보다 쉽습니다. add step (단계 추가)을 클릭하기 만하면됩니다.

어려운 점은 한 구성에서 병렬로 단계를 수행한다는 것입니다. 예를 들어, 커밋 후 병렬 린트, 유닛 테스트, 컴파 일을해서 약간의 시간을 절약하고 싶습니다. solution을 찾았지만 파이프 라인을 보거나 유지하기가 더 어려워졌습니다.

TeamCity는 작업 그룹화 문제를 해결하는 프로젝트에서 여러 구성을 지원합니다. 프로젝트를 그룹화하는 옵션을 찾지 못했습니다.

Answer 1

TeamCity은 무료로 제공되는 JetBrains의 Java 기반 CI 서버입니다. 우리는 매우 다른 종류의 프로젝트를 위해 그것을 매우 성공적으로 사용 해왔고, 나는 당신에게 그것을 절대적으로 추천 할 것입니다.각 요구 사항에 대해 :

• 빌드 파이프 라인은 빌드 구성 내에서 일련의 단계로 구성됩니다. 프로젝트는 임의의 수의 구성을 가질 수 있으며, 차례대로 임의의 수의 단계를 가질 수 있습니다.
• LDAP 통합이 완벽하게 지원됩니다.
• 빌드 파이프 라인을 병렬로 실행할 수 있습니다. TeamCity 대표는 빌드 구성 단계를 수행하는 데 필요한 모든 도구 (프레임 워크 등)가있는 일반적으로 별개의 서버 인 빌드 에이전트로 작업합니다. TeamCity의 무료 버전에는 3 명의 에이전트에 대한 라이센스가 제공되므로 최대 3 개의 빌드를 병렬로 실행할 수 있습니다. 추가 요원은 저렴한 비용으로 면허가 부여 될 수 있습니다.
• '계층 적 프로젝트'는 하나의 빌드 파이프 라인 완료로 인해 자동으로 후속 파이프 라인의 시작을 트리거한다는 것을 이해합니다. 이것은 지원되며 일관성을 위해 스테이지간에 빌드/버전 번호를 전달할 수 있습니다.
• XUnit에는 일류 지원이 있습니다. 보풀/컴파일러 보고서는 나중에 쉽게 검토 할 수 있도록 빌드의 '아티팩트'로 저장할 수 있습니다. 본질적으로, 많은 프레임 워크는 TeamCity에 내장 된 지원 기능을 가지고 있으며 다른 모든 기능은 임의의 쉘 명령을 실행할 수 있습니다. 출력은 아티팩트로 저장되거나 후속 빌드 단계에서 사용될 수 있습니다.
• 위에서 언급 한 것처럼 슬레이브/에이전트 지원은 TeamCity 모델의 핵심입니다.

이 모든 것은 구성 및 사용자 정의가 가능합니다. 우리는 TeamCity와 함께 다양한 다양하고 복잡한 작업을 수행 할 수 있었으며 완전히 견고하고 안정적이었습니다. 서버 대시 보드는 정보를 쉽게 이해할 수 있도록 정렬합니다.

Answer 2

면책 조항 : 본인은 Atlassian에서 근무하고 있으므로 조금 편견이 있습니다.

Bamboo에서 빌드 파이프 라인을 구성하는 것은 매우 쉽습니다. Bamboo는 계획 → 단계 → 직무 구조를 기반으로 운영되며 상위에서 하위로 나열됩니다. Bamboo Plan Structure을 확인하십시오.

Bamboo의 모든 프로젝트에는 계획 모음이 있습니다. 계획은 하나 이상의 단계로 구성됩니다. 단계는 순차적으로 실행되며 하나 이상의 작업으로 구성됩니다. 작업은 병렬로 실행되며 하나 이상의 작업 (순차적으로 실행되는 작업이지만 병렬로 실행되고 빌드 시간이 단축되도록 별도의 작업에 배치 할 수 있음)로 구성됩니다. 대나무의 에이전트는 빌드 단계를 수행하는 기계 또는 서비스입니다. 전체 작업은 단일 에이전트에서 실행됩니다. 상담원 here에 대해 자세히 알아볼 수 있습니다. 슬레이브 태그의 경우 특정 에이전트를 특정 빌드 나 프로젝트에만 배타적으로 묶을 수있는 기능이 새로운 기능의 짧은 목록에 포함됩니다.

는 다른 지점에 대답하려면 : LDAP/권한에 따라

• 사용자 인증을 LDAP 그룹/프로젝트를 기반으로 : 당신은 사용자 및 권한을 관리하기 위해 외부 LDAP 서버에 연결할 수 있습니다. Bamboo에는 그룹 기능이 있습니다. 또는 팀에서 JIRA를 사용하는 경우 JIRA 그룹을 활용하여 전역 권한을 설정하고 권한을 계획하며 계획의 빌드 결과에 대한 알림을받을 사용자를 지정할 수 있습니다. 계획 사용 권한은 계획 및 작업에 대해 특정 작업을 수행 할 수있는 사용자를 제어하는 ​​반면, 전역 사용 권한은 누가 계획 및 Bamboo 서버에 액세스 할 수 있는지 제어합니다.

• 계층 적 프로젝트 (프로젝트/구성 그룹) : Bamboo는 하위 & 하위 계획 구조를 지원합니다. 빌드를위한 트리거링을 설정할 수있는 여러 가지 방법이 있습니다.그 중 하나는 다른 빌드에서 트리거를 트리거하는 것입니다. 즉, 다른 빌드를 성공적으로 빌드 한 후에 또는 다른 특정 계획이 성공적으로 빌드되면 계획 빌드가 트리거됩니다. 예 : 계획 A가 성공적으로 빌드되면 계획 B &의 빌드가 자동으로 트리거됩니다.

• 보고서 xUnit, Lint, 지원에는 Maven/Maven2, Ant, make, MSBuild, NAnt, Grails, devenv.exe 및 모든 xUnix 호환 프레임 워크 (JUnit, Selenium, JWebUnit, NUnit, PHPUnit 등)가 포함됩니다.