Deploying updates to a web-server application will be a bit trickier with more parameters to deal with, but not conceptually different.
Dealing with the databases, however, is another thing entirely. The database, unlike other software components and code or compiled code, is not a collection of files. It is not something you can just copy from your development to testing and to production, obviously, because the database is a container of our most valued asset—our data. It holds all application content, customer transaction, etc. Business data must be preserved.
Unlike Java, C#, or HTML files or compiled code, a database shouldn’t be copied; it should only be altered at its target environment to mimic exactly the changes that we need to promote from our source environment (moving from development to testing to production, etc.). In order to promote database changes, a transition code needs to be developed; scripts to handle database schema structure (table structure), database code (procedures, functions, etc.), and content used by the application (metadata, lookup content, or parameters tables).
In future articles, I will discuss strategies for automating the complex changes to the database within the framework of agile software methodology and, especially, DevOps.
DevOps is a natural evolution of the software industry; it's not a revolution.
As business needs are the most significant driver of change, we are now doing more with less and delivering robust features faster. The database and the DBAs need to be first-class stakeholders in the DevOps revolution!