DevOps Version Control

Separate Development and Operations environments

1. Create and modify functionality in a separate Development environment.
2. Create a version and deploy it to the Operations QA environment for testing and approval.
3. When approved deploy the version to the Operations production environment.
   

*DevOps Version Control enable organizations to maintain the confidentiality, integrity, and availability of sensitive information assets by segregating developing, testing, and production environments through appropriate procedures, controls, and policies. You can design the migration or data-integration solution in the development environment then test it separately in the test environment before submitting it for production. Versioning is supported and you can produce multiple versions of the solution during its lifetime.

How to configure and use DevOps Version Control

You create the DEVELOPMENT environment from a copy of the Operations production environment.

• When using the default local-database repository it is a simple file copy, automatically managed from the Account window.
• When using SQLServer repository you manually make a copy of the production environment database and then connect to that database and promote it to be the development environment. The promotion process is managed from the Account window.
  

Once the development environment is created you can make changes as needed and at an appropriate time decide to make a version from the “DevOps Version Control” window.

When creating a new version, what happens is that all changes made are “collected” and stored in a version-package that you can then export to a file that you in turn can apply to the operations QA or production environments.

Segments of functionality and data that are NOT under version control and hence excluded from version packages	Not under version control
Variables	Data value Current value
Session log	Session log data
Job Server	Job scheduling

*Separating Databases and SharePoint sites in Development from Operations
You can use Variables in the SharePoint connections and Database connection to dynamically point to relevant testing/production resources.
It is recommended to use Variables that share their value across sessions since the Current value is permanently stored and is not under version control.

*Rollback support
If you want to to rollback to a previous version you can do so by restoring a backup of the repository database.
It is recommended to backup the repository database prior to applying a new version. By doing so you have a “good save point” to restore from.

! Making changes in the Operations environment
When using version control, any changes made to the Operations environments must also be made to the Development environment.

Copyright © 2024 MigrateDMS