continuous delivery: moving to different versions

Question

lets say: I have few environments, A, B and C (or development, staging and production) I have application X
I have multiple versions of application (X), V1, V2, V3
each version of X has its corresponding configuration (C) {V1->C1, V2->C1, V3->C2}
-by configuration I refer to passwords, key files, etc that is unique per environment

My expectation is to deploy software (each commit) quickly with appropriate config somehow up to staging quickly without any manual intervention but release to production will require release manager pressing a button somewhere.

questions:

1. do one make associations between app version and config set V->C?

   • do one persist the association if made?

2. how do one choose the right combination of (application version, config version/set) when roll back to some earlier version is required in any one environment?

Answer 1

It depends on where you store configuration.

• You can store it in version control, side by side with your source code. This makes the pairing question irrelevant, since configuration is necessarily in sync with the source.

  When it comes to sensitive data, version control systems such as SVN make it possible (and easy) to define in a granular way who can access what, ensuring that only a team working on the actual project can view and modify private keys and passwords.

  The major issue I encountered with this approach is when you need to access configuration from a location where you can't access the version control (especially if you don't like the idea of creating system accounts for your SVN server). I solved it by creating a product which let me to configure and audit the accesses to sensitive information, but simply giving a read-only access to the SVN may be easier in most situations.

• You can store it somewhere else—in a MongoDB database, for instance. In this case, you'll need to pair it with the version control yourself. Since you are talking about continuous delivery, I'm not sure why are you talking about versions; in all cases, each document within the database can contain, among the configuration itself, the minimum revision number. This way, if you have configuration for revisions 2789, 2801, 2816 and 2817, you can tell that a revision 2804 should use the configuration associated with revision 2801, not the other three.

  It can also be the other way around. You may have an identifier of the configuration version in your database, and use it in the source code to identify which configuration should be applied. This is particularly useful for distributed version control systems, since their revision numbers are not incremental.

  The drawback of keeping configuration separately from your source code is that it's very easy to forget to change the revision number/configuration version identifier, introducing bugs which could be difficult to debug. In my opinion, the approach makes sense only if the configuration is managed by persons other than developers—usually system administrators. If this is your case, I would suggest to look into DevOps, where developers are also in charge of the deployment of their app; in this context, storing configuration together with the source in a version control makes perfect sense.

Answer 2

do people generally make associations between app version and config set V->C?

how do people choose the right combination of (application version, config version/set) when roll back to some earlier version is required in any one environment?

"People" don't do things like this "generally" in software development. There are dozens of ways this can be implemented in software, and the "right" way depends on a hell lot of things. For example,

• how many installations do you have for your application?
• does each kind of installation have a different config?
• will each kind of installation allow lots of users with different configurations?
• what life cycle has your application and how does the config structure change throughout the life cycle (is it backwards or upward compatible?)
• what kind of backup/restore infrastructure is available and can configurations easily be backuped together with the application?
• Is it a database application, a destop app, a server app, a smartphone app, an embedded app?
• can there multiple versions be installed in parallel in one environment?
• What happens when a configuration gets lost, can it easily be restored / recreated?

Just to give you one example: MS Office came in versions "2003", "2007, "2010", "2013" etc. You can mostly install them in parallel, each version with a separate configuration, for each user, and probably a machine specific configuration, too. User specific configurations are stored in different folders per version, one could theoretically backup and restore them individually (though I guess the majority of Office users don't do this, if the machine fails, they will install the program again and recreate their original configuration manually). And as you see, for this kind of application both suggestions of @MainMa are fully unsuitable: there is neither a "version control system" nor a database where the user config could be stored.

Other programs might work completely differently, because if a config gets lost, a critical production system might fail, which might have a serious financial impact for their business. So you have to look at your kind of application, switch on your brain and decide under what category it falls.