forked from nicoespeon/gitgraph.js
-
Notifications
You must be signed in to change notification settings - Fork 0
Expand file tree
/
Copy pathtrunkDevModel.html
More file actions
56 lines (44 loc) · 2.44 KB
/
trunkDevModel.html
File metadata and controls
56 lines (44 loc) · 2.44 KB
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
<!DOCTYPE html>
<html>
<head>
<link href="https://cdnjs.cloudflare.com/ajax/libs/gitgraph.js/1.11.4/gitgraph.css" rel="stylesheet">
<meta name="viewport" content="width=device-width, initial-scale=1, maximum-scale=1, user-scalable=no, minimal-ui">
</head>
<body>
<p style="margin: 20px"></p>
<canvas id="gitGraph" style="padding: 20px"></canvas>
<script src="https://cdnjs.cloudflare.com/ajax/libs/gitgraph.js/1.11.4/gitgraph.js"></script>
<script src="trunkDevModel.js"></script>
<p style="page-break-before: always">
<h2> Pros</h2>
<ul>
<li>Everything works off of master.</li>
<li>Used by very large software development firms in social media space (eg google, facebook etc).</li>
<li>origin/master would be the main branch where the source code of HEAD always reflects a production-ready state.</li>
<li>origin/master would also reflect a state with latest delivered development changes for next release.</li>
<li>Frequent merges to master.</li>
<li>Well suited for CI/CD and automation of various elements in the build, test, deploy toolchain</li>
<li>Less stress during release time since almost everyday is release day! :)</li>
</ul>
<h2> Cons</h2>
<ul>
<li>Frequent merges to master.</li>
<li>Requires hyperfocus by entire team to solve problems immediately as they arise.</li>
<li>Requires high levels of confidence in the implementation of static analysis, dynamic analysis, code review, CI/CD and automation processes throughout the software design&development process.</li>
<li>Usually requires large software development and support team to stop team from getting blocked on an issue.</li>
<li>Products must have a very large customer base so that even a small problem would affect a large enough segment of users and the problem would become visible immediately to be reproduced, tested and addressed fast. (eg even if gmail fails for a small number of users, it becomes immediately visible through social media, so either the problem is solved or changes rolled back immediately before more damage is done to the codebase). This approach assumes "latent unidentified bugs" to be minimal in the products. Also assumes very little technical debt.</li>
<li>Products should also be extensively used by developers and internal users in the firms to raise defects asap.</li>
</ul>
<p></p>
<button onclick="myFunction()">Print</button>
<script>
function myFunction() {
window.print();
}
</script>
<br>
<br>
<br>
</html>
</body>
</html>