Newer
Older

Angelina Elizabeth Uno-Antonison
committed
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
# Standards and Definitions
[TOC]
## 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

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.


### 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](dev-getting-started.md).
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.

### 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](#level-of-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](merge-requests.md).
### 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.