CODEWITHSUNDEEP
svnbuildcontinuous-integrationjenkinsconfiguration-management
ziggy
ziggy

Reputation: 15876

Continuous Integration with Subversion and CVS

In the project i currently work on, we use both Subversion and CVS. Developers would usually develop code and check in to CVS/Subversion.

When coding is complete and everything has been checked in we tag the repository using a test label and carry out formal testing using code checked out using the TEST label.

We don't tag using the trunc instead we use the previous tag:

- Tag RELEASE.0.1 as PROJ-ABC-LIVE.1.3
- Tag revision 12 as PROJ-ABC-LIVE.1.3 (new changes not part of RELEASE.0.1)

The above ensures that only files from the last release + the new revisions are tagged with the new release label and thus excluding anything that has not been tested.

When testing is complete and any additional changes are made to the code (as a result of testing) the code is then tagged with a LIVE tag. The LIVE tag is the code that is checked out and deployed on to the LIVE server.

At any one time, the trunc of the repository can include any number of changes that people have made. In some cases, people would check in code changes that are 'In progress' and are incomplete. It is perfectly normal for someone to check in something and go on a two week holiday.

As an example here is a sample status of a revision file on our repository

1.4
1.5
1.6 PROJ-ABC-TEST.0.1
1.7 
1.8 PROJ-ABC-TEST.0.2
1.9 PROJ-ABC-LIVE.1.3
1.10
1.11

When we make a release we would check out everything with the tag PROJ-ABC-LIVE.1.3 and deliver that as a formal release. Revisions 1.10 and 1.11 are not included as those are new changes currently in trunc.

I am having a hard time to understand how something like Jenkins or Hudson would be used in this scenario. What exactly would it do for us if we do introduce it.

If we do introduce it, would it not just build the same release every time? We only build using tags so if i introduce Jenkins/Hudson i would have to configure it to build by tag. Would it not just build PROJ-ABC-LIVE.1.3 everytime it runs? Unless it is possible to build using the latest tag.

Most of the examples i have seen of how CI is used is that most people build from trunc everytime there is a change (commit) in the repository. How would this work if people check-in incomplete artifacts? I don't really see what is the benefit of building from TRUNC if the trunc is never stable (Which it is not meant to be).

Maybe i am not very knowledgeable about CM but how is it possible to release something that is built from Trunc? I guess my questions are

Thanks

Upvotes: 3

Views: 876

Answers (1)

malenkiy_scot
malenkiy_scot

Reputation: 16615

The short answer (as @JB is heavily hinting) is that you are not using a CI process at all - so CI server would not help you much. I would strongly recommend that your team switches to a CI process. Here is a seminal paper by Martin Fowler on what it's all about. Good luck!

Upvotes: 3

Related Questions