Had an amusing conversation with a developer at work that had the feeling of an abbot and costello bit. I’m leaving his name out of this to protect him, but he’s read this site before and will know instantly that it’s him. The conversation revolves around our new continuous integration system, and how the terminology has changed.

BTW, QA=Quality Assurance, UAT= User Acceptance Testing (staging)

(10:50:50 AM) morgajel: ok, so after talking to mick, it looks like my suspicions were correct
(10:50:54 AM) morgajel: there is no QA
(10:51:04 AM) morgajel: the name QA is misleading.
(10:51:16 AM) DeveloperX: hmmm
(10:51:25 AM) morgajel: trunk is for development, release is for qa, uat and prod
(10:51:26 AM) DeveloperX: what do u mean
(10:52:47 AM) DeveloperX: i have a release branch…
(10:52:50 AM) morgajel: think about it- anything going to QA is being marked as a release.
(10:53:12 AM) morgajel: so so release gets deployed to QA, then if it passes it goes on up the chain to production
(10:53:52 AM) DeveloperX: this is how the system currentlyis
(10:54:23 AM) DeveloperX: it seems to make snese to me? assueming nothing makes it ti UAT unlees it goes through QA
(10:54:36 AM) morgajel: that’s the way it should be.
(10:54:49 AM) DeveloperX: i think thats how it is
(10:54:57 AM) morgajel: the difference between this and the old system is, rather than labelling it projectX[QA], they’re now calling projectX_release_
(10:55:07 AM) DeveloperX: no? i only have a trunk and a release
(10:55:11 AM) morgajel: that’s the main difference for you
(10:55:20 AM) DeveloperX: which means the only thing goingto UAT will be from the release
(10:55:51 AM) morgajel: correct- the only thing going to qa or uat or prod will be from the release.
(10:56:12 AM) DeveloperX: so why can’t we still call it QA?
(10:56:42 AM) morgajel: because it’s *more* that QA- QA was a bad name for it from a organizational perspective
(10:57:32 AM) DeveloperX: is his only going to affect me, or is this the new approach for everyone?
(10:57:40 AM) morgajel: for everyone
(10:58:27 AM) DeveloperX: so your saying there is no pointin multiple srevers?
(10:58:33 AM) morgajel: no
(10:59:04 AM) morgajel: I’m saying whatever we put on UAT should be the EXACT same thing as QA
(10:59:13 AM) DeveloperX: so we will still push from trunkto release to UAT?
(10:59:20 AM) morgajel: and whatever we put in prod should be the EXACT same thing as both of them.
(10:59:24 AM) DeveloperX: it is
(10:59:28 AM) DeveloperX: currenlty
(10:59:29 AM) morgajel: well, from your side, here’s what happens
(10:59:37 AM) DeveloperX: at least for anything i;ve worked on
(10:59:44 AM) morgajel: you guys develop in trunk, and when you’re ready to release, you mark it as release.
(10:59:53 AM) DeveloperX: k
(10:59:55 AM) morgajel: then the QA people will check out release to the QA servers
(11:00:04 AM) DeveloperX: k
(11:00:10 AM) morgajel: once they give it a go, we will check it out to UAT,
(11:00:22 AM) DeveloperX: k
(11:00:24 AM) morgajel: once that’s good, it will be checked out from release toprod,
(11:00:54 AM) DeveloperX: put the code that is working it’s way up is exacly the same in each instance
(11:01:12 AM) morgajel: correct- as it should be.
(11:01:18 AM) DeveloperX: it is jsut being push multiple times, to make sure everything will work when we finally hit orid
(11:01:20 AM) DeveloperX: prod
(11:01:27 AM) morgajel: correct
(11:02:06 AM) morgajel:
now, I’m not sure what the exact mechanism will be for pushing to uat
and prod- we may check it out directly from svn, but more likely than
not, we won’t.
(11:02:33 AM) DeveloperX: ya, i would guess not
(11:02:37 AM) morgajel: the important thing is we can say “release 11234234 of projectX” and can match it up with a specific commit in subversion.
(11:03:50 AM) DeveloperX: i gotcha there…we used to havesomethiing like that, but it completely maintianed by me
(11:04:16 AM) DeveloperX: i have a new release branch for every deployment i make to projectX
(11:04:34 AM) DeveloperX: so I code in theory go back to 3deployments ago
(11:04:46 AM) DeveloperX: but you guys should have access to this…not just me
(11:05:35 AM) DeveloperX: make sense?
(11:08:09 AM) morgajel: you’re close
(11:08:23 AM) morgajel: I’m presuming you’re talking about http://buildserver/svn/projectX/branches/, correct?
(11:08:32 AM) morgajel: each of those listed is a different release branch, correct?
(11:09:01 AM) morgajel: what they’re doing is instead of creating a folder for each release, they’re creating a single folder
(11:09:17 AM) morgajel: and making note of the commit version when they commit acode to it
(11:10:14 AM) morgajel: hence when subversion says “committed version #1123223”,you’d call it “release 1123223” in your notes
(11:10:30 AM) morgajel: I think that’s what brandon is trying to aim for, but we’ll have to have him verify.
(11:11:00 AM) DeveloperX: ok, i think i gocha