jenkins - Continuous Integration Workflow & SVN -

ok may long one.

i'm trying standardize , professionalize setup have @ workplace doing live updates our software. currently, manual; have opportunity start scratch.

i have installed jenkins, have repositories work with, have job template (based on http://jenkins-php.org) , have current workflow in mind:

• main repository, 'trunk' sat on development server in own virtual host
• each developer creates branch specific bug/enhancement/addition, own virtual host

1) first question: @ stage, recommended practice run jenkins job/build once developer commits branch? run unit tests , other stuff (as per template linked above)

• once developer branch has been tested, approved, etc - lead developer merge of branch trunk

2) @ stage, jenkins job re-run again once merge complete. possible, , correct way this?

• once merge process has been tested , approved, deployment (im guessing can added task/target deploy job occurs automatically upon tests being passed in step above?) live site.

3) have read somewhere people have trunk checked out on live site, , deploy task svn update rather doing ftp task of files. again, correct way this?

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
im confused jenkins workspace. template using set dump folder of build/ workspace. svn set option, seems checkout of project workspace. intention of workspace , once populated?

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
update:

on deployment live servers ... seems have 3 options:

1) have checked out copy of trunk on live site, .svn files , directories hidden .htaccess, , run svn update once ready. advantages of are, fast, can rolled back. downsides are, security issues?

2) svn export either live folder directly (taking site down temporarily during process) or other folder , change apache vhost new location

3) use rysnc or similar tool?

which better option, or there better 1 missing?

usually, continuous integration, work done developers done on single branch (or on trunk). in fact, subversion designed type of workflow in mind. having work on same branch may sound scary. after all, collisions? if want include 1 bug/enhancement/addition, not in next release?

my experience forcing development take place on single branch works better. forces developers make small, careful changes , work each other. order issues (bug fixes , enhancements) handled must done @ beginning of development cycle instead of attempting pick , choose them @ end. managers flexibility of picking , choosing @ end, means massive merge cycle few days before release results in rushed testing.

if decide use private branching, recommend setup two jenkins instances. first official one. build off of trunk , release branches, not developer branches. jenkins unit testing. store artifacts required release. report on tests. qa team pull releases testing. allowed setup jobs on jenkins.

the other developers. can setup job , run tests on if want. their branches -- private branches or bug fix branches.

in answer first question: wouldn't bother running jenkins on private branches @ all. private branches used called sandboxes because developers play their. joke developers pretty did in sandbox kitty cats did in sandboxes. enforcing continuous integration on private branch takes away purpose of branch. care once code delivered trunk.

that's why recommend 2 jenkins setup. first you. execute build whenever commit/check in happens. second developers private branch. they'll setup jobs if want , execute build when want. sole purpose developers make sure work once code delivered trunk.

doing way avoids question #2: build after code delivered trunk because that's when commit done.

the last one, how code placed on server more of mystery. jenkins creating delivery artifact. can talk released via jenkins build number.

"let's release build #25 on production server."

"wait, qa never tested build #25, tested build #24."

"okay, let's release build #24, see has issue us232 fixed in anyway."

by way, use curl or wget pull software off of jenkins , onto our server. in fact, have deploy.sh script use. pull deploy.sh script jenkins, , run that. automatically pulls down right build jenkins , installs it. shuts down server, backups old install, installs new software, restarts server, , reports results.

however, there's idea of subversion doing deliveries you. various methods used. 1 subversion update automatically @ particular time off of production branch. put code on production branch, , @ 2:00am every morning, subversion deliver code. it's neat idea, , i've done -- when you're talking php doesn't have compiled.

i prefer first method since have more control , forces deploy jenkins builds. plus, there issue cause svn update method of deployment fail (collision, unversioned file needed removed, etc.). , of course, happen @ critical time. and, of course, spectacular failure happens right before boss fills out annual review.

so, in response third question. preferred method not involve subversion. instead, ftp built artifacts (using wget , curl) directly off jenkins server, , run true deployment script handles that's required.

by way, looking @ various deployment tools liverebel integrate jenkins. idea jenkins build deliverable package , deploy liverebel, can use liverebel deploy our servers. aren't sure whether each jenkins build deployed liverebel, or use build promotion plugin let qa select builds deploy liverebel. second prevent deploying builds qa hasn't certified.

addendum

thanks reply , insight. reason looking @ per-task branching number of reasons:

i'll respond each of reasons...

1) - allows tasks done in isolation main trunk.

and tasks can done in isolation each other too. problem resulting code isn't isolated these tasks , these tasks may incompatible each other.

a lot of managers think isolation allow them pick , choose tasks include in next release , they'll able @ release time. 1 of first true cm packages called sablime at&t , based upon philosophy.

in sablime, have generic call release. base changes. each change assigned modification request (mr number), , work must done upon mr.

you create next generic taking old baseline generic, adding in selected mrs, , tada! new generic can created. sounds simple: old baseline + selected changes = new baseline.

unfortunately, mrs affect files same files. in fact, wasn't uncommon new generic contain version of file not written actual developer. also, 1 mr ended depending upon another. manager declare mrs 1001, 1003, , 1005 in next release. try add these mrs baseline, , find out mr 1003 dependent upon mr 1002 dependent upon mr 1008 1 don't want release. spend next week trying work out set of releasable mrs , end releasing software never thoroughly tested.

in order solve issue, ended smaller changes between baselines. new generic each week, 2 of them. allowed make sure merging worked, , made sure dependent mrs included first before mrs dependent upon them. however, eliminated entire pick , choose concept. left lot of overhead built sablime.

2) no time constraints - each task can take time being completed, , doesnt impact on other tasks.

tasks impact each other unless 2 different software packages run on 2 entirely different machines 2 separate databases.

all tasks have time constraint because there cost associated time, , benefit associated task. task takes long time, provides little benefit not worth doing.

one of jobs of development prioritize these tasks: should done first, , should done later. tasks take long should broken subtasks.

in agile development, no task suppose take more resources sprint can afford. (a sprint mini-release , covers 2 week period.) in 2 week period, developer has number of points can fulfill (points sort of related hours, not really. assume 1 point represents x hours of work thought experiment.) if developer can 15 points per week, task takes 30 points big sprint , must divided subtasks.

3) - release , deployments can done on per-task basis, rather waiting other tasks completed , multi-task release @ fixed point in time (what trying away that)

none of i'm saying means can't task based development. sites use git lot. agile process assumes this. none of implies go waterfall method no 1 allowed touch keyboard until every single excruciating detail has been laid out. however, can't fifty separate tasks , day before release pick , choose ones want include. don't release tasks, release software product.

use task branching. far concerned, task not complete until changes in trunk. developers responsible this. must rebase (merge changes trunk branch), test rebased code , deliver (merge changes trunk) before project can consider task complete.

this why tell you can have 2 jenkins instances: 1 official build on trunk , release branches, , 1 developers task building. developers can have fun in world jenkins , branches , development. doesn't count until it's on trunk , build jenkins.

think of git , how linux works. there 1 official git repository linux. pull repository , creates own git repository on machine. can share git repository friends. can ever heart desires. can create git repo git repo, or pull copy of official git repo or find else git repo of linux , pull there.

however, of changes not considered part of linux until changes pushed 1 , official git repository.