Comments posted to this topic are about the item Continuous Delivery
Follow me on Twitter: http://www.twitter.com/way0utwest
Forum Etiquette: How to post data/code on a forum to get the best help
My Blog: www.voiceofthedba.com
I agree that a key concept of Continuous Delivery (CD) is that CD <> Continuous Release.
Not all development deliveries are suitable releases and the criteria for a development delivery is a subset of those for a release. You should always be able to go back to any release, in fact to any delivery.
The key skills in achieving this is good management of source control. What I am referring to is primarily branching and merging. I have worked on projects where this has been achieved for the database through scripts, however, due to the complexities of databases sometimes a manual procedure has needed to be performed. In those cases documenting and storing the release process is more important than ever to achieve the requirement to be able to repeat any delivery (and, hence, all releases).
-- Stop your grinnin' and drop your linen...they're everywhere!!!
Hall of Fame
From my experience it can be difficult to do continuous delivery if there are real big changes to back ends.
For Enterprise Data Applications I have found that the key to continuous delivery for me is getting the structure of the data in your backend correct from the start (Good Normalisation adherence usually covers it for me). If you know the domain well you should be able to add in extra tables / fields in the knowledge that you might need them later. Large changes in backend almost negate continuous delivery as not only do you change the backend structure but sometimes you need to migrate the data in the backend. If that backend is being continuously updated it can be impossible to prevent loss of data without a downtime when you say to people "do not add or edit information the system between this time period".
I generally practice continuous delivery but the times I have had to do say to people the system is going to be down its because I had to make biggish changes to the backend and data had to be transferred and manipulated, downtime could not be avoided.
Yeah, we actually have a similar own built tool that we use ourselves and have others use. That's proof of concept =)
Viewing 4 posts - 1 through 3 (of 3 total)