How do developers stage database changes locally when using global versioning?

[lholman]

EDITED: from original as frankly it was a poor question first time around....

We have a batch script called DEV.DBDeployment.DropCustomCreate.bat, as the name suggests this drops and creates our db from a fresh, a useful tool in Dev but we don't always want to drop the database, sometimes just get the latest changes.

It's worth noting currently every CI checkin triggers a build in TeamCity which pumps the current Major.Minor.BuildNumber.Revision (e.g. 1.0.123.1568) number in to all AssemblyInfo.cs files within all Visual Studio projects. This obviously allows us to stamp the resultant dll's with the build number, pretty standard stuff for sure. We also overwrite a BuildInfo.txt file in a similar way, most importantly this BuildInfo.txt file is included within every deployment package and sits within the RoundhousE\deployment folder and is referenced by /vf=%version.file% when we run rh.exe as mentioned above from the .bat file. So we're sorted for deploying to existing databases in Test and Prod.

However in dev the AssemblyVersion is always 0.0.0.0 in AssemblyInfo.cs, as is the version number in BuildInfo.txt (for obvious reasons), therefore how do devs stage their changes locally against their database. For example, with this setup when we run rh.exe all changes will be stamped with the version number 0.0.0.0, regardless. Is the expectation that in dev you will always drop and create? If that's the case I'm assuming we need TeamCity to checkin the BuildInfo.txt file so RoundhousE can reference it from source control when executed in dev?

Is there something I'm missing here?

[ferventcoder]

You mean local dev?

[ferventcoder]

How are you guys keeping local databases up to date? are you using one of the refresh database projects that is out there to make it super simple?

Or are you building and running a batch file?

[ferventcoder]

And now to answer your question - I don't agree with taking a dependency on a build server for your automated build. Sure, one of those numbers is probably the build number, but locally that number could always be zero and the other numbers filled out. Having the revision as one of the numbers should give you confidence that you are very close to the same version out there (although you haven't committed yet so if you have changes there is nothing that will give you a completely accurate number).

I'm of the mind and recommendation that your automated build should be executable locally so that it is repeatable on all dev computers. It also reduces the setup of the build server (jenkins, team city, etc) to a simple contract instead of having it do more than it should.

What happens when your build server goes down? How do you ensure you are not breaking the build (I know, private checkin verification with Team City VSIX, but it doesn't apply to all build servers)? What about bringing up a new build server of a different type like Jenkins?

Having the automated build be able to execute locally gives you a much quicker and reliable feedback cycle into knowing you have not broken the build, which builds confidence and stronger teams who check in more often. ;)

Okay, now that I've ranted a bit -

If you must pull the versioning from TC, you will likely need to check it in so that local folks can get it.

[lholman]

yes, local dev...I'm moving them away from a single shared database.

[lholman]

building and running a batch file at the moment, I've lifted the schema and can build a minimal dataset that allows the application to come alive. All other data loading for test is/to be automated through the application API.

[lholman]

"I'm of the mind and recommendation that your automated build should be executable locally so that it is repeatable on all dev computers."
Couldn't agree more and I suppose this is the reason I'm at this point as I am also moving all the custom inline TeamCity Powershell build steps to checked in psake tasks and encouraging devs to execute these locally.

I suppose I should really just accept that I need to decouple specific local dev database versions from production, simple as that, i.e. checkin in a star to the AssemblyVersion (0.0.0.*) in AssemblyInfo.cs and be done with it and don't try to compare local dev versions to Test or Prod?

The database versioning in TeamCity is then used to provide an immutable database version number, as we do with the deployable application assemblies themselves.

Simples!!??

[ferventcoder]

There is a tremendous value in being able to test the bugs in a version of prod. Not having that global variable would be a bad thing.

[ferventcoder]

As long as you keep the immutable version builds that do go to production and don't delete them at some point in Team City you should be good to repro bugs.

[lholman]

There is a tremendous value in being able to test the bugs in a version of prod. Not having that global variable would be a bad thing.

Agreed, I wasn't suggesting not utilizing a global variable, rather questioning what the scope of that global variable is, as our previous comments seem to suggest it isn't really possible to use the global variable on local dev databases?
When you say a "version of prod" are you suggesting simply restoring a full or subset of a prod database?

As long as you keep the immutable version builds that do go to production and don't delete them at some point in Team City you should be good to repro bugs.

Are you suggesting you use those immutable version builds to deploy to dev locally and build a new db from scratch (minus prod data) for debugging issues? We can always run a custom build in TeamCity to generate those artifacts again so that isn't of a major concern to me.

I can't help but think I'm missing something fundamental about configuring global versioning, I've re-read the wiki but feel the outcome for Global versioning is the same as you mention here https://github.com/chucknorris/roundhouse/wiki/Versioning#why-is-script-number-versioning-non-global i.e. the local dev databases can't match the same global version numbers as all the environments we formerly deploy to.

Some implementation examples would be ideal but I can't seem to find any relevant resources.

[ferventcoder]

We use uppercut to ensure versioning matches where it matters. The only number that would be off is the build number, and that's just an education thing.

You can also set up for using semantic versioning with uc and then carry some dev tag with a date on it until it is ready to release.

[ferventcoder]

We are building a shared assembly file that all of the projects get their version number from. That's the key in affecting a good versioning strategy. That might be the piece you are missing.

[lholman]

Cheers Rob, it's becoming clearer now I understand that you don't expect to keep the build number in sync downstream to devs, saying that though, are you checking that shared assembly in each time, I expect not? We too share versions across all projects so that's not a problem.

[mpareja]

Our build infrastructure (in our source control) takes care of the product
version generation. The build infrastructure will check to see if a
TeamCity build number is available via an Environment Variable and append
that if available.

Regarding assembly information, I usually see folks generate the
AssemblyInfo file at build time rather than having one checked into source
control.

Cheers,

Mario Pareja

On Thu, Jun 20, 2013 at 11:31 AM, lholman notifications@github.com wrote:

Cheers Rob, it's becoming clearer now I understand that you don't expect
to keep the build number in sync downstream to devs, saying that though,
are you checking that shared assembly in each time, I expect not? We too
share versions across all projects so that's not a problem.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/113#issuecomment-19761069
.

[ferventcoder]

We don't check it in since it is generated by the automated build. It detects the environment variable BUILD_NUMBER (I believe for TC) and adds the build number if present, otherwise leaves a zero.

[ferventcoder]

@mpareja nailed it. 👍

[lholman]

Cheers guys. I think the missing piece was that I was concerned about getting the latest build number locally and I couldn't stitch together the missing link, that makes sense to grab it from your build server of choice if available. To summarise, how it all comes together.

Major -> Relatively static, provided by build scripts
Minor -> Relatively static, provided by build scripts
Build -> Grab from build server (API/Environment variable, whatever mechanism you prefer) for the given revision (or 0 if not available)
Revision -> From source control obviously

And the following is stitched together locally when you run your build on the commandline, which in our case gets latest, compiles, runs tests and drops/creates the db (optional).

Regarding assembly information, I usually see folks generate the
AssemblyInfo file at build time rather than having one checked into source
control.

@mpareja We overwrite it as part of the build but the checked in version is always 0.0.0.0, so horses for courses really.

Thank you both for your time on this.

[ferventcoder]

Cool, closing... :)

[lholman]

I've created a simple gist of my implementation of this https://gist.github.com/lholman/5982608

[mpareja]

That's pretty much what we do. Include TeamCity's build number if available
and then output the ##teamcity directive to get the full string back into
team city.

On Fri, Jul 12, 2013 at 3:38 AM, lholman notifications@github.com wrote:

I've created a simple gist of my implementation of this
https://gist.github.com/lholman/5982608

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/113#issuecomment-20862622
.