PHP 프로젝트의 전개/빌드/CI 사이클 설정

PHP 프로젝트의 전개/빌드/CI 사이클 설정

저는 주로 PHP를 기반으로 하는 대규모 프로젝트에 종사하며 대부분의 시간을 혼자 개발합니다.코드 베이스의 변경의 처리 방법을 전문화 및 자동화해, 근본적인 변경 없이 팀으로 이행할 수 있도록 하는 Continuous Integration 프로세스를 작성하고 싶다.

지금 하고 있는 것은 프로젝트마다 로컬 테스트 환경을 갖추고 있습니다.프로젝트마다 SVN을 사용하고 있습니다.변경사항은 로컬로 테스트되고 나서 보통 FTP를 통해 온라인 버전으로 전송됩니다.API 문서는 소스 코드에서 수동으로 생성됩니다.유닛 테스트는 제가 천천히 진행하고 있는 문제이며, 아직 일상 업무의 일부가 아닙니다.

제가 구상하는 '빌드 사이클'은 다음과 같습니다.

• 변경 세트는 로컬에서 테스트된 후 SVN에 체크인됩니다.

• 빌드 프로세스를 시작합니다.SVN HEAD 리비전은 체크아웃되고 필요에 따라 수정되며 업로드 준비가 됩니다.

• API 문서는 자동으로 생성됩니다.아직 상세하게 설정하지 않은 경우 기본 템플릿을 사용하여 전체 코드 베이스를 스캔합니다.

• 새로운 리비전은 FTP(디렉토리 이름 변경, chmoding, 데이터베이스 Import 등)를 통해 리모트로케이션에 전개됩니다.이것은 내가 이미 매우 좋아하는 것이지만, 물론 나는 다른 방법을 선택할 준비가 되어 있다.

• 사전 정의된 위치에 있는 장치 테스트가 실행됩니다.이메일, RSS 또는 (가능하다면) HTML 출력을 사용하여 웹 페이지에 저장하여 실패 또는 성공을 알 수 있습니다.

• (옵션) 사전 정의된 위치에 있는 최종 사용자의 "changelog" 텍스트 파일은 커밋 메시지의 사전 정의된 부분으로 업데이트됩니다("foo"와 "bar"를 동시에 필터링할 수 있게 되었습니다).이 메시지는 SVN 커밋메시지와 반드시 동일하다고는 할 수 없습니다.SVN 커밋메시지에는 내부 정보가 많이 포함되어 있을 수 있습니다.

• 코드 메트릭스, 코드 스타일 체크 등은 현시점에서는 중점적으로 다루지 않지만, 장기적으로 보면 반드시 그렇게 될 것입니다.이를 바로 사용할 수 있는 솔루션은 매우 친절하게 검토되고 있습니다.

찾고 있습니다

• 비슷한 상황에 있거나 비슷한 상황에 처해 있으며 이를 위한 솔루션을 성공적으로 구현한 사람들로부터의 피드백과 경험

• 특히 설정 방법에 대한 단계별 튜토리얼과 워크스루

• 새로운 프로젝트별로 스켈레톤 API, 테스트 케이스 등을 작성하여 가능한 한 많은 자동화를 제공하는 솔루션.

그리고 또

• 제품 권장 사항지금까지 알고 있는 것은 빌드에는 ping/ant, 리포트 부분에는 phpUnderControl 또는 Hudson입니다.제가 보기에는 다 좋지만, 물론 자세한 경험은 없습니다.

저는 일이 많아서 간단한 해결방법이 강합니다.한편, 기능이 없는 경우는, 너무 한정되어 있다고 울어 버립니다.:) 포인트 앤 클릭 솔루션도 환영입니다.또한 PHP 프로젝트와 연계할 수 있는 상용 제품 추천에 찬성합니다.

내 셋업

저는 Windows에서 로컬로 작업하고 있으며(정확히는 7개), 대부분의 클라이언트 프로젝트는 LAMP 스택, 종종 공유 호스팅(= 원격 SSH 없음)에서 실행됩니다.저는 제 환경에서 실행할 수 있는 솔루션을 찾고 있습니다.이것으로 Linux VM을 셋업 할 준비가 되었습니다.문제 없습니다.호스팅된 솔루션은 설명된 모든 측면을 제공하거나 프로세스의 다른 부분과 상호 작용할 수 있을 만큼 유연해야 흥미롭다.

보너티 나는 내가 가장 많은 마일리지를 얻을 수 있을 것 같은 대답을 받아들인다.여기에는 훌륭한 입력이 많이 있습니다.여러 가지 답변을 받을 수 있으면 좋겠습니다.여러분 감사합니다.

빌드봇, CruiseControl.net, 크루즈 컨트롤 및 허드슨에 대해 알아봤습니다.저는 CruiseControl*을 정말 좋아했지만, 정말 복잡한 종속 케이스로 인해 너무 번거로웠습니다.buildbot은 셋업이 쉽지 않지만 좋은 아우라를 가지고 있습니다(저는 비단뱀을 좋아합니다, 그게 전부입니다).하지만 허드슨은 이전 세 명을 이겼다.

1. 셋업은 간단합니다.
2. 커스터마이즈하기 쉽다
3. 외관도 좋고 개요 기능도 좋다.
4. 포인트 앤 클릭 업데이트를 통해 자체 및 설치된 모든 플러그인을 관리할 수 있습니다.이건 정말 좋은 기능이고, 점점 더 고맙게 생각합니다.

주의: 지금까지 Linux를 사용한 것은 상기 빌드 서버(CC.net는 mono 상에서 실행)의 베이스로서 뿐이었습니다만, 문서에 의하면, 모두 크로스 플랫폼을 실행할 필요가 있습니다.

허드슨 서버 설정

전제 조건:

• Java (1.5면 충분합니다)
• 하위 버전 서버에 대한 읽기 액세스 권한(Hudson 사용자에 대한 별도의 계정이 있음)

여기서부터는 그냥...

java -jar hudson.war

이렇게 하면 콘솔에서 바로 작은 서버 인스턴스가 실행되며 설치는 다음 사이트에서 참조할 수 있습니다.http://localhost:8080사전에 그 포토상에서 동작하고 있는 다른 포토가 없는 경우(다른 포토를 지정하는 경우는,--httpPort=ANOTHER_HTTP_PORT위의 명령어에 대한 옵션)과 '설치' 프로세스가 모두 잘 진행되었습니다.

사용 가능한 플러그인 디렉토리로 이동하는 경우(http://localhost:8080/pluginManager/available위 작업을 지원하기 위한 플러그인이 있습니다(버전 지원은 기본값에 따라 설치됩니다).

원하는 경우 tomcat이나 jetty와 같은 Java 응용 프로그램서버를 인스톨 할 필요가 있습니다.모든 주요 응용 프로그램 서버에서 설치 절차를 사용할 수 있습니다.

업데이트: 가와구치 고스케가 허드슨용 윈도 서비스 설치 프로그램을 구축했습니다.

허드슨에서 프로젝트 설정

다음 워크스루의 링크는 다음 위치에 있는 허드슨의 실행 인스턴스를 가정합니다.http://localhost:8080

1. 새 작업 선택(http://localhost:8080/view/All/newJob왼쪽 메뉴에서 )을 클릭합니다.
2. 작업의 이름을 지정하고 체크 표시Build a free-style software project명부에.
3. '확인'을 누르면 작업의 구성 페이지로 이동합니다.모든 옵션에는 물음표가 붙어 있습니다.이 옵션을 누르면 옵션에 대한 도움말 텍스트가 표시됩니다.
4. 'Source Code Management' 옵션 그룹에서 Subversion을 사용합니다.Hudson은 URL 액세스와 로컬 모듈 액세스를 모두 허용합니다.
5. 'Build Triggers' 옵션 그룹에서는 'Poll SCM'을 사용합니다.여기서 사용되는 구문은 cron의 구문이기 때문에 5분마다 서브버전 저장소를 폴링하면*/5 * * * *
6. 프로젝트 빌드 프로세스는 옵션 그룹 '빌드'에서 지정됩니다.이미 개미 빌드 파일에 필요한 모든 대상을 가지고 있다면 운이 좋은 거야그냥 '개미 불러오기'를 선택하고 목표물의 이름을 쓰세요.옵션 그룹은 maven 및 shell 명령도 즉시 지원하지만 ping에 사용할 수 있는 플러그인도 있습니다.
7. '빌드 후 작업'에서 추가 빌드 작업(예: 전자 메일 알림 또는 빌드 아티팩트 아카이브)을 체크하십시오.

허드슨에 플러그인이 없는 프로세스를 설정하려면 빌드 설정 내에서 셸 스크립트를 통해 프로세스를 직접 호출하거나 자체 플러그인을 쓸 수 있습니다.

함정:

• 빌드 아티팩트를 생성하는 경우 허드슨에게 정기적으로 뒷정리를 시키는 것을 기억하십시오.
• 20개 이상의 프로젝트를 설정한 경우 빌드 상태를 허드슨에 기본 기본 페이지로 표시하지 않는 것이 좋습니다.

행운을 빕니다.

찾고 있는 용어는 "지속적인 통합"입니다.

다음은 GIT + phpundercontrol을 사용하는 사용자의 예입니다.http://maff.ailoo.net/2009/09/continuous-integration-phpundercontrol-git/

CruiseControl(CI 서버)은 Hosted SVN/GIT를 소스로 사용할 수 있습니다.GitHub이나 Beanstalk 등에서도 사용할 수 있습니다.

그런 다음 이를 다음 종류의 소프트웨어와 통합할 수 있습니다.

• PHUnit
• php-interniffer
• php documentor
• PHP Gcov
• PHPXref
• 야스카
• 기타.

다음 호스트 CI를 사용해 보십시오.http://www.php-ci.net/hosting/create-project

단, 이러한 툴을 직접 통합하려면 커스텀 지원이 필요합니다.

프로젝트 관리 및 패치 관리에 대해서도 생각해 본 적이 있습니까?

Redmine을 프로젝트 관리에 사용할 수 있습니다.지속적인 통합 지원을 제공하지만 클라이언트 측에서만 통합됩니다(CI 서버로는 통합되지 않음).

SVN/GIT/etc. 호스트형 솔루션을 사용해 보십시오.SVN/GIT/etc 솔루션이 백업을 커버하고 서버를 계속 가동하기 때문에 개발에 집중할 수 있습니다.

Hudson 설정 방법에 대한 튜토리얼은 http://toptopic.wordpress.com/2009/02/26/php-and-hudson/를 참조하십시오.

저는 Atlassian의 Bamboo continuous integration 서버를 주요 PHP 프로젝트에 사용하고 있습니다(다른 제품과 함께 fishheye(리포지토리 브라우징), jira(이슈 트래커), clover(코드 커버리지) 등).

SVN을 지원하며 Git을 지원하며 뛰어난 사용자 인터페이스를 갖추고 있습니다.Linux, Windows 및 Mac에서 사용할 수 있으며 자체 Tomcat 서버에서 스탠드아론 방식으로 실행할 수 있습니다.저와 같이 툴을 셋업하는 데 며칠이 걸리는 것을 좋아하지 않는 사용자에게 매우 적합합니다.비싸 보일 수도 있지만, 혼자 개발했기 때문에 스타터 키트 라이선스를 10달러(소프트웨어 기준 10달러)에 구입했습니다.이것은 소규모 팀에게 매우 적합하며 볼만한 가치가 있습니다.

PHPTesting PHPCI 이것은 php에 내장된 멋진 연속 통합 서버입니다.

게다가 무료 오픈 소스입니다.:)

플러그인의 수가 있습니다.

PHPCI에는 다음을 위한 통합 플러그인이 포함되어 있습니다.

• 아툼
• 베하트
• 캠프파이어
• 코드인셉션
• 작곡가
• 이메일
• 그룬트
• IRC
• PHP
• 보풀
• MySQL
• PD 엔드
• 포스트그레스Ql
• PHP 코드 순이퍼
• PHP 복사/붙여넣기 디텍터
• PHP 사양
• PHP 장치
• 셸 명령어
• 타르 / ZIP

저는 주로 시스템 관리자이지만 가끔 PHP를 코드화하기도 합니다.부프로젝트로서 Jenkins를 사용하여 PHP CI 환경을 완전히 구축하는 것을 간단하고 쉽게 할 수 있는 스크립트를 작성했습니다.또한 샘플 프로젝트를 실행하여 각 빌드 단계가 어떻게 구성되었는지 확인할 수 있습니다.

시험해 보고 싶다면 Debian/Ubuntu 박스와 셸 액세스만 있으면 됩니다.

http://yauh.de/articles/379/setting-up-a-ci-environment-for-php-projects-using-jenkins-ci

업데이트 내 답변에 일부 내용을 추가하려면:

Ansible을 사용하여 Jenkins CI for PHP를 설정할 수 있습니다.v1.4는 galaxy.ansibleworks.com 커뮤니티 사이트에서 다운로드할 수 있는 역할을 지원하므로 많은 작업을 수행할 수 있습니다.그것은 jenkins-php라고 불린다.

Jenkins http://jenkins-ci.org/을 사용하는 것은 무료이며 오픈 소스입니다.

셋업이 매우 간단하며 여러 플랫폼에서 작동하며 SonarQube(+SQUALE)와 같은 기타 지속적인 통합 도구와 잘 통합되어 기술적 부채를 측정하고 자동화 테스트를 위한 Thucydides를 지원합니다.

버전 관리는 SVN 대신 GIT나 GIT Hub를 사용하는 것이 좋습니다.제 관점에서는 나중에 개발 작업을 확장하는 데 도움이 되는 더 나은 버전 관리 시스템일 뿐입니다.

당신은 주로 PHP 프로젝트로 작업하고 있기 때문에 다른 툴을 사용할 수 있습니다.

PHPUnit - 유닛 테스트용

PHP CodeSniffer - 코딩 표준을 확인합니다.

PHP 종속성 - PHP 코드 종속성을 표시합니다.

XDEBUG - 퍼포먼스 테스트용

이러한 모든 도구는 Jenkins 작업으로 트리거되며 코드의 품질과 성능에 도움이 됩니다.

행운을 빌며 즐겨요!

저는 당신이 사용하는 제품이나 타입의 제품을 많이 사용하지 않지만, 제 경험을 알려드리겠습니다.

I run a TEST environment in parrallel with my PROD environment. I have no local testing per se. If it is too hard to get soemthing up into a real TEST environment, then I fix my build process. I don't see the point in testing locally, as the environments are different. UPDATE: The only thing I do locally is run "php -l" before I upload anything. Stops the stupid mistakes.

The build process works with whatever is in the current workspace, which includes uncommitted code. This is not everyone's cup of tea, but I am going to TEST very often. Everything gets committed before going to PROD.

Part of my build process (similar to yours) creates two META files. One contains the last (typically) 100 changes and also gives me the current changelist number. The shows me what changes are installed. The other contains the CLIENTSPEC (in Perforce terms) which shows me exactly what branches were used in this build. Together these give me reproducible builds.

I do not build straight to the target environment, but to a staging area on the server. I use SSH so this makes sense. This gives me a few advantages. Most importantly it avoids dying half way through a large upload. It also gives me a place to store META files, and all the build files are automatically archived (so I can go straight back to any build). The script also logs the update (so there is an entry in the log stream and I can see pre- and post-) and kicks all daemons (I use daemontools so "svc -t"). All of these are better off on the target machine.

One other issue is DB changes. I keep a master script of the DB schema, which I update every time the schema changes. Each of the changes also go into a changes.sql script, which is uploaded with the build to the staging area. The script is run as part of the install script.

I've recently begun the same kind of process, and am using Beanstalk for svn hosting.

There are two nifty features in the paid accounts (start at $15pm i think):

• deployment allows the user to create ftp targets for staging and production servers, which can be deployed at the click of a button (inc specifying a revision and branch)
• webhooks allow the user to set up a url that is called on each commit/deploy, passing across things like revision number, description and user. This could be used to update docs, run unit tests and update changelogs.

I'm sure there are other hosted or self-hosting svn servers with these two features, but beanstalk is the one i have experience of and it's working very, very well

There's also an API, which I imagine could be used to integrate deployment further in to your process.

Consider fazend.com, a free hosted CI platform, which automates configuration and installation procedures. You don't need to setup version control, bug tracking, CI server, test environment, etc. Everything is done on-demand.

ReferenceURL : https://stackoverflow.com/questions/2180460/setting-up-a-deployment-build-ci-cycle-for-php-projects