Deploying after every 2 weeks is a challenge

[Jitu]

One of the challenges of being agile is the deployment. We use
"capistrano" for automated deployment in our rails applications.

Giving deployment in every 2 week requires a great deal of confidence
on the stability of the application. Automated unit, functional and
user acceptance test gives us the confidence to go for the deployment.

[nhm tanveer hossain khan (hasan)]

hi jitu bhai,
thanks for nice topic, as we know potential shippable product must be
deployed after every sprint.
we keep tester and QA process with in the scrum team and sprint, so on
the last stand up meeting QA persons can speak out if anything (or any
bug) might mess up the whole system.

usually we keep separate release milestones, so our continuous or
after sprint deployments go to the test server.
we (in my new company tekSymmetry) are planning to give our client
access to the test server.

after few sprints when we are ready and confident enough to announce a
new version, we deploy them in production environment.
so you see our existing server are not getting unstable sprint outcome
rather they are getting when we are ready with stable release.
definitely if you want to deploy every outcome of the sprint to the
production server, i agree with you, that requires a lot of confidence
and verifications processes as well.

i'd suggest keep separate milestones for production environment (only
stable version will go to production) and let everyone see what's on
test environment.

something similar we have been following -

[sprint 1] [sprint 2] [sprint 3] [sprint 4] [sprint 5] [sprint 6]
[sprint 7] [sprint 8] [sprint 9] [sprint 10]
[ release 1 ] [ release
2 ] [ release 4 ]


thanks once again for nice topic :)_)
best wishes,

[Jitu]

Thank you Hasan vai for sharing your thoughts. This surely illuminates
the topic more.

Some times it gets very difficult to resolve all the bugs at the end
of the sprint and fix those.
And people are more concern about not producing a new bug by resolving
the old.
That is why continuous integration helps us to find out a bug very
early.

Another experience worth of sharing is that, previously we gave our
test release on Tuesday
and production on Wednesday, if everything goes well. After test
release we work on
client feedback and fix issues, which some times take a lot of time.

So we took another approach by giving partial test release with in the
sprint. We provide the
list of stories, which have been deployed to test server. So that we
can get partial feedback early.
And we find this very helpful for our timely deployment.

There are some issues we faced about synchronizing the team to give a
partial test release.
We predefined a partial test release date and committed our stable
codes, ran all the test,
fixed test codes, and then give a partial test release.


On Jul 26, 12:05 pm, "nhm tanveer hossain khan (hasan)"

[Morshed Alam]

Thanks Hasan vai and Jitu for sharing your thoughts.
I think there is an another good option to identify and resolve some
bugs earlier by quick "sprint review" session at the test release day.

In that session we have reviewed our sprint's works by using projector
(but it is not necessary to use projector). It is very helpful to
deliver better product. Because at that time all of the team members
attend the session and put their feedbacks. Most of the time we got
lots of feedback from that session and fixed that earlier.

So, It may be an good option to deliver better product.

[nhm tanveer hossain khan (hasan)]

you know what morshed bhai ?
you are right projector or big screen is good way to review the sprint
work, we are gonna buy one with in few weeks.
thanks for mentioning this once again.

best wishes :)_)