Suppose a deployment pipeline is going on. SVN tagging and development version change is going on. At that time a developer is committing his changes. so there is a chance that CI server releasing the new committed untested changes to the production or some other conflicts occure. How can I handle this situation. Do I need to lock the entire trunk until the build pipeline completes. Is there any other work around.
Asked
Active
Viewed 228 times
-1
-
1"CI server releasing the new committed untested changes to the production " - erm, what? – Mitch Wheat Oct 21 '13 at 13:42
-
Suppose CI server is going to start the last step in Deployment pipeline, which is the process of tagging the source code in trunk to a specific version and then committing the trunk to change the current development version to next snapshot version. Just before this step a crazy developer commits his changes to trunk. So if the ci server tags the trunk just after this commit it will tag these changes also, which is not there in the released binary. were i succeeded to explain this situation? – user2903314 Oct 22 '13 at 05:37
-
In my view, a CI server should not be deploying to production. – Mitch Wheat Oct 22 '13 at 05:37
1 Answers
1
If I understand correctly, you assume the following steps
- after a commit, the build server will check out the current trunk (let's say revision A),
- perform the build,
- execute some tests,
- tags the trunk if the tests are successful
- and deploys to production (still only if tests are successful)
The "crazy" developer commits between step 3 and 4 and thus creates revision B. Now you assume that the build server will again check out the latest revision (which would be revision B). This behaviour could indeed cause some trouble.
However, the build server should do all the steps based on a specific revision which is not a problem in common setups. E.g. Jenkins usually has a check-out step at the beginning of the job. If there is a tagging step in the end, you will usually not want that Jenkins blindly tags the current trunk (causing the problem you describe) but instead tag the revision that is checked out in Jenkins' workspace.
Additionally, please consider that there should be at least some manual approval step before anything gets deployed automatically to production. This is usually mentioned in the context of continuous delivery as far as I can see.
The key to continuous delivery is IMHO that you are able to deploy the current version of your source code at any time at the push of a button. IMHO it does not mean that every commit should be deployed automatically.
Martin Klinke
- 7,294
- 5
- 42
- 64
-
We can tag in two ways. 1. copy trunk: eg: svn copy http://mydomain.com/myproject/trunk http://mydomain.com/myproject/tags/1.0.0. 2. copy – user2903314 Oct 22 '13 at 08:38
-
We can tag in two ways. 1. copy trunk: eg: svn copy http://mydomain.com/myproject/trunk http://mydomain.com/myproject/tags/1.0.0 2. Copy local working copy eg : svn copy . http://mydomain.com/myproject/tags/1.0.0 So inside CI server we should always tag from the checkout copy used for building and testing. Am I right? – user2903314 Oct 22 '13 at 08:49
-