Skip to content
Snippets Groups Projects

Standards and Definitions

Types of Development

Every type of work that touches code within the CGDS is identified either as Research, Development, or R&D.

Research

This role identifies scientists within CGDS that specialize in research utilizing their software development skills. A lot of this research involves discovery of applications of machine learning using clinical and omics data. Successful research from within this group shall feed into the products that the team develops.

Development

This role identifies software engineers within CGDS that specialize in crafting commercial grade analysis products for omics data analysis in translation and clinical research.

R&D

R&D work is the collaboration of Research and Development. Once the research is ready to be used beyond discovery or personal use, researchers and developers collaborate and create a path forward for integrating the work into production.

Project's Level of Visibility

Screenshot

Every project within the CGDS is categorized by the level of its visibility relative to the center. The level of visibility influences the standards, expectations, and practices within a CGDS project. Additional requirements are required as a project escalates in visibility.

Screenshot

Screenshot

Discovery

This work is quantified as tasks where a person investigates to better understand a subject or technology better.

Personal Use

This is software the is developed and used only by yourself for projects and is not shared amongst the team.

In House Use

Software that has become applied and is regularly used more two or more team members. Projects that are utilized in house must be migrated to be within the Center for Computational Genomics and Data Sciences.

External Use

The software being developed has users outside of the center but is available for immediate collaborators to use.

Open Source

Software that is publicly available and allows the community to contribute to contribute to the application.

Standard Practices

Integrated Development Environments (IDE)

CGDS' goal is for everyone to develop IDE agnostic. Standardizing code in projects will rely on static analysis tools such as linting to enforcing coding practices specific to programming languages and software. Modern IDE's can be configured to recognize the lint configuration files within CGDS projects.

Source Control

CGDS hosts source code within a self-hosted Community Edition of GitLab that is maintained by UAB IT's Research Compute group. To learn more about getting started with UAB's GitLab, visit Getting Started.

The development team (research, R&D, and development) practices feature branch development. The following diagram demonstrates how the team uses feature branch development with git via the command line. Using Git in the command line is not require. Team members are free to use different Git tools as long as they follow the Git flow below. Screenshot

Peer Reviewing

Peer reviews are a type of software review in which a work product (document, code, or other) is examined by one or more colleagues in order to evaluate its technical content and quality.

Once the work is completed (coding,unit testing,linting, etc), the code is ready to be merged into the master version of the project in the orign/master branch hosted on GitLab.

Each merge request must pass the peer review criteria according to its level of visibility in order to be accepted to merge into master. Visit project visibility to learn more.

Everyone's goal is to automate as many of the manual peer reviewing tasks as possible to help reduce human error and usage of developer work time.

To learn more about CGDS' merge request process, visit Merge Requests.

Dependency Locking

Dependency management is a technique for declaring and resolving the dependencies required by a project in an automated fashion. Dependency locking is a technique that explicitly defines the dependency versions created from a dependency management software. This often results in generating a lock file that is then added to source control. Lock files are then used to pull the exact versions of the dependencies in order to build the application.