The Difference Between Source Control for Native Code and for the Database
As developers flock to DevOps for its speed and efficiency, it's important to note the differences between most projects and databases.
Join the DZone community and get the full member experience.Join For Free
an ever-increasing number of organizations are implementing devops using a continuous delivery process. they are fueled by reports of the benefits, which include quicker time to market, reduced costs, and higher quality products.
every organization has its own processes for compiling native code. it can be manual or automatic using jenkins, bamboo, etc., and the build system can be maven, make, or others. but all builds have one thing in common that the build process relies on.
each build starts with an empty folder, then gets the relevant source code files from the file-based version control repository (svn, git, perforce, microsoft tfs, ibm rtc, etc.). it then compiles the source code files, and, if the compilation succeeds, the process can continue to the next step, which is to deploy to an automated test environment. some organizations also save the compilation phase output (binary artifacts) result in a binary source control repository (svn, git, perforce, tfs, rtc, etc.) so the deployment process can retrieve the relevant artifacts from the file-based (binaries) source control repository.
deployment to an automatic test environment process can be done differently in diverse organizations. one company might do it manually, a second might run scripts, and third might use an application release automation tool, such as ibm urbancode deploy or ca release automation . the common factor for all deployments is copying the artifact (binary) to the relevant server while overriding what was done before.
every change a developer makes must be documented in the source control repository. if it doesn't exist in the source control repository, it is not included in the build process. furthermore, if a developer copies an artifact generated locally to a test environment, the next deployment will override this out-of-process change.
occasionally, defects will only bed recreated in test environments, but due to infrastructure limitations (like storage, costs, and complex architecture) the developer is required to work in the test environment and not in the development environment. in those cases, the developer may need to copy the locally generated artifact directly to the test environment. once the developer checks in the code changes, the next deploy to the test environment will override the locally generated artifact with an artifact from the binaries source control. this built-in safety net in the process prevents out-of-process, locally generated artifacts from entering into the production environment.
the database code has similar characteristics to native code but also has some inherent differences, which require adjustments to the source control infrastructure from perspectives of native code development, build, and deploy.
a database code deployment is done by running sql scripts (ddl, dcl, and dml), which change the current structure and data to the desired version. when comparing database deployment to native code deployment, the differences are crystal clear. native code deployment is done by copying the new binaries (dll, jar, etc.) to the target environment. the previous version of the artifact is no longer valid and may be saved for a quick rollback. this is the safety net that prevents out-of-process artifacts from reaching the production servers.
this is not the case with database code deployment. the script changes version a to version z via many ddl, dcl, and dml commands — with every command changing the version a little bit. if the current version of the database is not a, there are two possible outcomes:
- the script will ignore current version and override the structure with whatever exists in the script.
- the script will fail. for example: trying to add a column that already exists with a wrong data type.
an error in a deployment process is not usually a desirable outcome. in this case, however, getting the error is better than having the script run successfully and then without warning, revert changes made to production as an emergency fix or changes made in the trunk/stash. these changes would have been made by a different team or merged from a different branch.
the input of the deployment phase is sql script(s), which are generated in the build phase.
Published at DZone with permission of Yaniv Yehuda, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.