Skip to main content

Sample Development Workflow

As DataOps.live follows the core principles of dev-ops, a vital part of that is the development workflow, promoting code through the standard environments before the final release into production.

Please note

This is a simplified, idealized workflow based on the most typical implementations of DataOps.live. You may wish to incorporate DataOps processes into their existing development workflows, so this sample procedure may not match your account's configuration exactly.

Feature branch​

Whether adding a feature or fixing a bug, development activity usually starts with a feature branch, created from the main development branch (typically dev in DataOps).

  1. Create a feature branch from dev - often done by opening the dev branch in the Web IDE and then committing the changes to a new branch.
  2. Develop and test in the feature branch, committing as needed.
  3. When the code is ready, create a Merge Request (MR) from the feature branch into dev.

Development environment​

  1. The development team reviews the MR and merges it into dev, deleting the feature branch if they agree with the code and test results.
  2. Perform integration testing of the new code - this often starts with a pipeline run immediately after merging the MR. Other features/fixes will usually be included in this process.
  3. When a set of development activities is ready, usually at the end of a development cycle (e.g., sprint), an MR is raised to promote the new code into the Quality Assurance environment (qa branch).

Quality assurance environment​

  1. The QA team will review the MR's code and tests before merging it into their qa branch if acceptable. Otherwise, there is usually some rework cycle between the QA and development teams to resolve any issues.
  2. Quality assurance test procedures are run. This may include existing unit tests, but dedicated QA test routines will often use separate infrastructure. This can be part of standard DataOps pipelines using configured jobs to only run in the qa branch.
  3. Once all QA testing is passed, the new code is ready for release into production. A merge request will be raised from the qa branch into the main branch.

Production environment​

  1. Production operators will review the MR and schedule the release if the code and QA results meet the required production criteria. As the release schedule dictates, the MR will be merged into production-ready for the next pipeline run.
Last updated on