We're not Continuous Integration. What are we?

I’m trying to figure out the proper terminology for our dev/test procedure.

  1. The main master codebase in bitbucket.

  2. Developers make their code changes (bug fixes, feature improvements) and create pull requests/feature branches that contain their code commits. They are not saved directly into master (so not CI). Each jira issue generally has one corresponding pull request.

  3. QA uses Jenkins to deploy individual (or sometimes multile) pull requests on top of the master to our test environments (each QAer has their own test server). So, we are able test the addition of just one change at a time. We do full functional testing and any regression testing we think might be relevant.

  4. After QA approves the change, we merge the pull request into the master.

I’ve worked in QA for 23 years and I’m very very happy with the system we’re using. Instead of dev giving us a full iterative version to test, we test and add the parts piece by piece. Nothing gets merged untested so we have great control and minimal risk.

I’m pretty sure it’s not Continuous Integration as I’ve read about it. I thought of the term controlled integration since we carefully check every little thing before it gets integrated, and I see that there is such a concept but I’m not sure that we’re doing that either. Or are we? Or something else?


Scott, just because you do not have a conveyor belt running continuously on the Mater branch, does not mean you cannot talk about what you do in the same room as someone who definitely does do CI in all it’s fullness.
Your step 4 is a “release” process of sorts, so once you formalise and automate more of that process, and remove the labour intensive bits in the process, without removing the human decision making of course. Then you are doing CI, and can join the cool kids with confidence. Not everyone has their code getting automatically promoted. In real life automatically promoting a build because it passed is not 100% going to happen, because integrations between teams and interface changes do break any logic a promoting script can employ because of change dependencies and even things like external components coming in and miss-communications between developers and test. Minimising these is important to the harmony of the software creation process.
I like the Controlled Integration term although it really plays on “Version Control” as a concept, and uses the power of regression testing because in my experience CI is about finding which build broke, and then which code change in that build broke things - which comes down to looking at bitbucket changes. I’ve only been doing this about half your time in the game, but I suspect that even swapping “Controlled Integration” for the similar in meaning term; “Change Integration” might remove the process connotation. In this light, I prefer your term as a way of speaking about the process you follow.