-2

I decided to use the following pattern after reading semantic versioning at http://semver.org/. However, I have some unsolved issues in my mind in terms of automaticng and integrating SDLC tools.

Version Pattern: 
major.minor.revision.build

Such that;

Major: major changes, should be increamented manually.
Minor: minor changes, should be increamented automatically, whenever a new feature or an enhancement to existing feature is solved in issue tracking system.
Revision: changes not affecting the minor changes, should be increamented automatically, whenever a bug is solved in issue tracking system.

Assume that developers never commit the source unless an issue has been solved in issue tracking system, and the issue tracking system is JIRA in this configuration. This means that there are bugs, improvements, and new features as issue types by default, apart from the tasks.

Furthermore, I am adding a continous integration tool in this configuration, and assume that it is bamboo (by the way, I never used bamboo before, I used Hudson), and I am using Eclipse IDE with mylyn plugin and plus the project is a Maven project (web).

Now, I want to elucidate what I want to do by illustrating following scenario. Analyst (A) opens an issue (I), which is a new feature, related to Maven project (P). As a developer (D), I receive an email about the issue, and I open the task via Mylyn interface in Eclipse. I understand and develop the new feature related to issue (I). Consider, I am a Test Driven Development oriented developer, thus I wrote the Unit, DBUnit, and User-Acceptance (for example using Selenium) tests correspondingly. Finally, I commit the changes to the source control. I think the rest should be cycled automatically but I don't know how can I achieve this? The auto-cycled part is the following:

The Source Control System should have a post-hook script that triggers the Continous integration tool to build the project (P). While building, in the proper phase the test code should be run, and their reports generated. The user-acceptance test should be performed in a dedicated server (For example, jboss, or Tomcat). The order of this acceptance test should be, up the server, run the UA test, then generate the UA test reports and down the server. If all these steps have been successfuly completed, the versioning should be performed. In versioning part, the Maven plugin, or what so ever, should take the number of issues solved from the Issue Tracking System, and increment the related version fragments (minor and revision), at last appends the build number. The fragments of the version may be saved in manifest file in order to show it in User Interface. Last but not the least, the CI tool should deploy it in Test environment. That's all auto-cycled processes I want.

The deployment of the artifact to the production environment should be done automatically or manually?

double-beep
  • 5,031
  • 17
  • 33
  • 41
st.
  • 166
  • 6
  • 24

1 Answers1

0

Let's start with the side question: On the automatic deployment to production, this requires the sign off of "the business" whomever that is. How good do your tests need to be to automatically push to production? Are they good enough that you trust things to just go live? What's your downtime? Is that acceptable? If your tests miss something, can you rollback? Are you monitoring production so you know if you've introduced problems? Generally, the answers to enough of these questions is negative enough that you can't auto-deploy there as the result of a build / autotest event.

As for the tracking, you'll need a few things. You'll need all your assumptions to be true (which I doubt they are, but if you get there that's awesome). You'll also need a build number that can be incremented after build time based on test results. You'll need source changes to be annotated with bug ids. You'll need the build system to parse the source changes and make associations with issues. You'll need an API into the build system so you can get the count of issues associated with the build. Finally you'll need your own bit of scripting to do the query and update the build number accordingly.

  • That's totally doable, but is it really worth having? What's the value you attach to the numbering scheme?
EricMinick
  • 1,487
  • 11
  • 12
  • About the side question; I think that I couldn't ask the question well. The testers should run their assigned test cases, and if the all test cases ended up as expected, should the deployment into prod. env. be the manuel or automated? In order to do this, is there an application for example, the test manager or release manager gets an email like "All the test cases of the app. version x.y.z.b have been completed, please check and start the auto-deployment of prod." – st. Dec 28 '11 at 07:58
  • About the versioning, what is your suggestion for versioning the app? If it is not automated, everytime we build the app, someone has to check the issues completed and bugs fixed and correct the version of the app. Where shall we keep the version information of a war, jar or ear? If the version information should be kept in manifest file, then the someone extract the archive and correct the file and update the archive? – st. Dec 28 '11 at 07:58
  • For automated deployment, I misunderstood the question. I actually firmly believe in push-button deployments. (My company, Urbancode, has been selling products around that for years). Where it gets tricky is if you want to deploy to production, as the result of passing automated tests -- every build might automatically go to production. – EricMinick Dec 28 '11 at 16:44
  • For app versioning, I think an auto increment is a great thing. You might just step away from trying to count the number of fixed features. [major].[minor].[build] is a decent pattern where both major and minor are manually updated. If you can pull off the counting of the fixes reliably, I think that would be exceptionally cool, but I'm not sure its worth the effort and I'm far from an expert in the API capabilities of Bamboo so I don't even know if its possible with your toolset. – EricMinick Dec 28 '11 at 16:46