• Anadi Misra

Release When Ready

How the automation of builds, testing and deployment can help smoother and shorter release in a fast paced Scrum based development.

Releases without a release cycle per say

Not something I have done but I plan to in near future, I've been asking myself the question on why can't be do a sprint demo on staging and put accepted stories to production? That would be a great value addition to the mature Agile development rythm that I find our teams here in Sony Ericsson. I'm sharing it here to get your views on my thoughts about how this "flow" could look like. Over the past months I have been working on adding Selenium RC based tests that can run through the site ( we have a mix and mash of JQuery, Velcoity, XHTML, and DWR in logic that belts out pages, or page regions), automated load test scripts running on a combination of ruby, ant and JMeter, and tweaking deploy scripts to use the dynamics that good Mr. Hudson can provide all in an attempt to ease out things for me and cut down time taken in a release. We have a two weeks sprint, and every alternate sprint developers are made to go over the same dichotomy, how to estimate development work in print while still keep buffer for the unplanned work that'll come their way in supporting releases. Over past few months they have tried a lot of things, estimating on 70% capacity and keeping buffer stories, one member in the team effectively signs up for 50% availability while the rest is to be used for release support etc. All of this do tend to break the development rhythm a bit and we've been wondering there has to be a better way! That lead us to this flow that I write below:

  1. Check before you commit

  2. I don't like code reviews; now just in case you are thinking of what happens to code quality? I add checkstyle/PMD config in all my developers' eclipse and block a checkin if there is a coding error or coding style error. Of course I have to trust them to run all tests locally before they commit, do not want tool auditing that part as I believe a culture of trust here is the best tool.

  3. Keep Deploying

  4. It does not stop at it just these continuous builds; each build is followed by the deploy, and each deploy is to be followed a whole suite of automated functional/regression tests and then automated load tests(thanks again to Selenium and JMeter). the idea is that I should be the first one to know when the site starts cranking due that new story I did (better than anyone else finding it out a few weeks later)

  5. Tests, more tests and even more tests

  6. not just unit tests here; I go by the philosophy that you should have a test written also for that new feature/functionality/layout change on the site. (I stumbled upon JSUnit so you can test first Java Scripts as well and keep adding to the test base) befoe you change a feature on the presentation tier, and run all of those as a suite which is 'reliable'.

  7. Do you need a release cycle then?

  8. I can just pick it up from my maven repo and deploy it to production. If not production at-least integration and leave it to the releavnt owner of enviroment beyond to follow their processes , but yeah, I might be throwing in another one to integration before they manage taking the first one to production :-).

A far fledged thought most of us would say, but then I'd be going ahead with this anyway and share you all my experiences.

4 views0 comments

Recent Posts

See All