mirror of
https://gitlab.com/Anson-Projects/projects.git
synced 2025-06-16 15:06:53 +00:00
wrap up content
This commit is contained in:
parent
40debcface
commit
73c45ca26e
@ -1,11 +1,11 @@
|
|||||||
---
|
---
|
||||||
title: "Continuous Integration and Systems Engineering"
|
title: "Continuous Integration and Systems Engineering"
|
||||||
description: |
|
description: |
|
||||||
A short description of the post.
|
Continuous Integration is helpful for more than running tests and pushing code to production. For example, my team is currently using it to build regular progress reports of our code to keep everyone updated with its status.
|
||||||
author:
|
author:
|
||||||
- name: Anson Biggs
|
- name: Anson Biggs
|
||||||
url: https://ansonbiggs.com
|
url: https://ansonbiggs.com
|
||||||
date: 09-27-2021
|
date: 10-04-2021
|
||||||
output:
|
output:
|
||||||
distill::distill_article:
|
distill::distill_article:
|
||||||
self_contained: false
|
self_contained: false
|
||||||
@ -15,6 +15,22 @@ categories:
|
|||||||
- Capstone
|
- Capstone
|
||||||
---
|
---
|
||||||
|
|
||||||
Working on a complex project that spans multiple domains can be really challenging for a small team. The small team size makes it hard not to keep every team member completely up to date on the inner workings of every system but that can add a ton of overhead and make progress slow to a halt. My [Capstone](https://projects.ansonbiggs.com/#category:Capstone) team makes this even harder since all but one of us are Astronautical Engineers. Astronautical is just a fancy way of saying "Systems, but every problem is a satellite" so a project like ours that has a massive Embedded software aspect can be really challenging since the most important part of the project is essentially a black box to a majority of the team.
|
## The Problem
|
||||||
|
|
||||||
To combat most of the team having zero knowledge of writing C++ for a microcontroller I opted to use Gitlab's CI to build and post results for every single commit that the repository sees. So far this has worked really well. The people in charge of other subsystems can look at the readme of the GitLab repo and see
|
Working on a complex project that spans multiple domains can be challenging for a small team. In addition, the small team size encourages every team member to keep entirely up to date on the inner workings of every system, but that can add a ton of overhead and make progress slow to a halt.
|
||||||
|
|
||||||
|
<aside>Teammates can also slow meetings to a halt or make poor contributions if tasked to contribute on a subsystem they aren't knowledgeable of.</aside>
|
||||||
|
|
||||||
|
My [Capstone](https://projects.ansonbiggs.com/#category:Capstone) team makes this even harder since all, but one of us are Astronautical Engineers. Astronautical is just a fancy way of saying, "Systems, but every problem is a satellite" so a project like ours with a massive Embedded software aspect can be challenging since the most crucial part of the project is essentially an enigma to a majority of the team.
|
||||||
|
|
||||||
|
So what we needed was a way for me to write code and to keep the rest of the team up to date without ever having to touch the code and ideally without me having to generate any kind of report manually.
|
||||||
|
|
||||||
|
## The Solution
|
||||||
|
|
||||||
|
With Continuous Integration and a little Python, my GitLab repository automatically builds the latest code, runs the code, produces plots with the results, and makes an executable available if someone is inclined to run the code themselves. The automation means that the project readme is always up to date, and if anyone is wondering how progress is proceeding, they can check the readme and view the current performance in an accessible format.
|
||||||
|
|
||||||
|
The data availability is also excellent for when my team has to produce a progress report because there is never waiting on the person who can run the code and then build some plots. Unfortunately, the same can't be said for the other teams who usually have difficulty compiling their progress into a pr
|
||||||
|
|
||||||
|
## The Result
|
||||||
|
|
||||||
|
All of the code being used for the Capstone is public, and the specific repository that I've been talking about can be accessed here: https://gitlab.com/lander-team/lander-cpp As you can see, the readme has charts that are always up to date. The `.gitlab-ci.yml` file contains all the build info, and you'll likely be surprised how simple of a setup it is.
|
||||||
|
@ -88,30 +88,30 @@ code span.wa { color: #5e5e5e; font-style: italic; } /* Warning */
|
|||||||
<!--radix_placeholder_meta_tags-->
|
<!--radix_placeholder_meta_tags-->
|
||||||
<title>Continuous Integration and Systems Engineering</title>
|
<title>Continuous Integration and Systems Engineering</title>
|
||||||
|
|
||||||
<meta property="description" itemprop="description" content="A short description of the post."/>
|
<meta property="description" itemprop="description" content="Continuous Integration is helpful for more than running tests and pushing code to production. For example, my team is currently using it to build regular progress reports of our code to keep everyone updated with its status."/>
|
||||||
|
|
||||||
|
|
||||||
<!-- https://schema.org/Article -->
|
<!-- https://schema.org/Article -->
|
||||||
<meta property="article:published" itemprop="datePublished" content="2021-09-27"/>
|
<meta property="article:published" itemprop="datePublished" content="2021-10-04"/>
|
||||||
<meta property="article:created" itemprop="dateCreated" content="2021-09-27"/>
|
<meta property="article:created" itemprop="dateCreated" content="2021-10-04"/>
|
||||||
<meta name="article:author" content="Anson Biggs"/>
|
<meta name="article:author" content="Anson Biggs"/>
|
||||||
|
|
||||||
<!-- https://developers.facebook.com/docs/sharing/webmasters#markup -->
|
<!-- https://developers.facebook.com/docs/sharing/webmasters#markup -->
|
||||||
<meta property="og:title" content="Continuous Integration and Systems Engineering"/>
|
<meta property="og:title" content="Continuous Integration and Systems Engineering"/>
|
||||||
<meta property="og:type" content="article"/>
|
<meta property="og:type" content="article"/>
|
||||||
<meta property="og:description" content="A short description of the post."/>
|
<meta property="og:description" content="Continuous Integration is helpful for more than running tests and pushing code to production. For example, my team is currently using it to build regular progress reports of our code to keep everyone updated with its status."/>
|
||||||
<meta property="og:locale" content="en_US"/>
|
<meta property="og:locale" content="en_US"/>
|
||||||
|
|
||||||
<!-- https://dev.twitter.com/cards/types/summary -->
|
<!-- https://dev.twitter.com/cards/types/summary -->
|
||||||
<meta property="twitter:card" content="summary"/>
|
<meta property="twitter:card" content="summary"/>
|
||||||
<meta property="twitter:title" content="Continuous Integration and Systems Engineering"/>
|
<meta property="twitter:title" content="Continuous Integration and Systems Engineering"/>
|
||||||
<meta property="twitter:description" content="A short description of the post."/>
|
<meta property="twitter:description" content="Continuous Integration is helpful for more than running tests and pushing code to production. For example, my team is currently using it to build regular progress reports of our code to keep everyone updated with its status."/>
|
||||||
|
|
||||||
<!--/radix_placeholder_meta_tags-->
|
<!--/radix_placeholder_meta_tags-->
|
||||||
<!--radix_placeholder_rmarkdown_metadata-->
|
<!--radix_placeholder_rmarkdown_metadata-->
|
||||||
|
|
||||||
<script type="text/json" id="radix-rmarkdown-metadata">
|
<script type="text/json" id="radix-rmarkdown-metadata">
|
||||||
{"type":"list","attributes":{"names":{"type":"character","attributes":{},"value":["title","description","author","date","output","draft","categories"]}},"value":[{"type":"character","attributes":{},"value":["Continuous Integration and Systems Engineering"]},{"type":"character","attributes":{},"value":["A short description of the post.\n"]},{"type":"list","attributes":{},"value":[{"type":"list","attributes":{"names":{"type":"character","attributes":{},"value":["name","url"]}},"value":[{"type":"character","attributes":{},"value":["Anson Biggs"]},{"type":"character","attributes":{},"value":["https://ansonbiggs.com"]}]}]},{"type":"character","attributes":{},"value":["09-27-2021"]},{"type":"list","attributes":{"names":{"type":"character","attributes":{},"value":["distill::distill_article"]}},"value":[{"type":"list","attributes":{"names":{"type":"character","attributes":{},"value":["self_contained"]}},"value":[{"type":"logical","attributes":{},"value":[false]}]}]},{"type":"logical","attributes":{},"value":[false]},{"type":"character","attributes":{},"value":["Systems Engineering","Capstone"]}]}
|
{"type":"list","attributes":{"names":{"type":"character","attributes":{},"value":["title","description","author","date","output","draft","categories"]}},"value":[{"type":"character","attributes":{},"value":["Continuous Integration and Systems Engineering"]},{"type":"character","attributes":{},"value":["Continuous Integration is helpful for more than running tests and pushing code to production. For example, my team is currently using it to build regular progress reports of our code to keep everyone updated with its status.\n"]},{"type":"list","attributes":{},"value":[{"type":"list","attributes":{"names":{"type":"character","attributes":{},"value":["name","url"]}},"value":[{"type":"character","attributes":{},"value":["Anson Biggs"]},{"type":"character","attributes":{},"value":["https://ansonbiggs.com"]}]}]},{"type":"character","attributes":{},"value":["10-04-2021"]},{"type":"list","attributes":{"names":{"type":"character","attributes":{},"value":["distill::distill_article"]}},"value":[{"type":"list","attributes":{"names":{"type":"character","attributes":{},"value":["self_contained"]}},"value":[{"type":"logical","attributes":{},"value":[false]}]}]},{"type":"logical","attributes":{},"value":[true]},{"type":"character","attributes":{},"value":["Systems Engineering","Capstone"]}]}
|
||||||
</script>
|
</script>
|
||||||
<!--/radix_placeholder_rmarkdown_metadata-->
|
<!--/radix_placeholder_rmarkdown_metadata-->
|
||||||
|
|
||||||
@ -1455,7 +1455,7 @@ code span.wa { color: #5e5e5e; font-style: italic; } /* Warning */
|
|||||||
<!--radix_placeholder_front_matter-->
|
<!--radix_placeholder_front_matter-->
|
||||||
|
|
||||||
<script id="distill-front-matter" type="text/json">
|
<script id="distill-front-matter" type="text/json">
|
||||||
{"title":"Continuous Integration and Systems Engineering","description":"A short description of the post.","authors":[{"author":"Anson Biggs","authorURL":"https://ansonbiggs.com","affiliation":" ","affiliationURL":"#","orcidID":""}],"publishedDate":"2021-09-27T00:00:00.000-07:00","citationText":"Biggs, 2021"}
|
{"title":"Continuous Integration and Systems Engineering","description":"Continuous Integration is helpful for more than running tests and pushing code to production. For example, my team is currently using it to build regular progress reports of our code to keep everyone updated with its status.","authors":[{"author":"Anson Biggs","authorURL":"https://ansonbiggs.com","affiliation":" ","affiliationURL":"#","orcidID":""}],"publishedDate":"2021-10-04T00:00:00.000-07:00","citationText":"Biggs, 2021"}
|
||||||
</script>
|
</script>
|
||||||
|
|
||||||
<!--/radix_placeholder_front_matter-->
|
<!--/radix_placeholder_front_matter-->
|
||||||
@ -1472,17 +1472,28 @@ code span.wa { color: #5e5e5e; font-style: italic; } /* Warning */
|
|||||||
<div class="dt=tag">Capstone</div>
|
<div class="dt=tag">Capstone</div>
|
||||||
</div>
|
</div>
|
||||||
<!--/radix_placeholder_categories-->
|
<!--/radix_placeholder_categories-->
|
||||||
<p><p>A short description of the post.</p></p>
|
<p><p>Continuous Integration is helpful for more than running tests and pushing code to production. For example, my team is currently using it to build regular progress reports of our code to keep everyone updated with its status.</p></p>
|
||||||
</div>
|
</div>
|
||||||
|
|
||||||
<div class="d-byline">
|
<div class="d-byline">
|
||||||
Anson Biggs <a href="https://ansonbiggs.com" class="uri">https://ansonbiggs.com</a>
|
Anson Biggs <a href="https://ansonbiggs.com" class="uri">https://ansonbiggs.com</a>
|
||||||
|
|
||||||
<br/>09-27-2021
|
<br/>10-04-2021
|
||||||
</div>
|
</div>
|
||||||
|
|
||||||
<div class="d-article">
|
<div class="d-article">
|
||||||
<p>Working on a complex project that spans multiple domains can be really challenging for a small team. The team size being small makes it hard not to keep every team member completely up to date on the inner workings of every system but that can add a ton of overhead and make progress slow to a halt. My <a href="https://projects.ansonbiggs.com/#category:Capstone">Capstone</a> team makes this even harder since all but one of us are Astronautical Engineers.</p>
|
<h2 id="the-problem">The Problem</h2>
|
||||||
|
<p>Working on a complex project that spans multiple domains can be challenging for a small team. In addition, the small team size encourages every team member to keep entirely up to date on the inner workings of every system, but that can add a ton of overhead and make progress slow to a halt.</p>
|
||||||
|
<aside>
|
||||||
|
Teammates can also slow meetings to a halt or make poor contributions if tasked to contribute on a subsystem they aren’t knowledgeable of.
|
||||||
|
</aside>
|
||||||
|
<p>My <a href="https://projects.ansonbiggs.com/#category:Capstone">Capstone</a> team makes this even harder since all, but one of us are Astronautical Engineers. Astronautical is just a fancy way of saying, “Systems, but every problem is a satellite” so a project like ours with a massive Embedded software aspect can be challenging since the most crucial part of the project is essentially an enigma to a majority of the team.</p>
|
||||||
|
<p>So what we needed was a way for me to write code and to keep the rest of the team up to date without ever having to touch the code and ideally without me having to generate any kind of report manually.</p>
|
||||||
|
<h2 id="the-solution">The Solution</h2>
|
||||||
|
<p>With Continuous Integration and a little Python, my GitLab repository automatically builds the latest code, runs the code, produces plots with the results, and makes an executable available if someone is inclined to run the code themselves. The automation means that the project readme is always up to date, and if anyone is wondering how progress is proceeding, they can check the readme and view the current performance in an accessible format.</p>
|
||||||
|
<p>The data availability is also excellent for when my team has to produce a progress report because there is never waiting on the person who can run the code and then build some plots. Unfortunately, the same can’t be said for the other teams who usually have difficulty compiling their progress into a pr</p>
|
||||||
|
<h2 id="the-result">The Result</h2>
|
||||||
|
<p>All of the code being used for the Capstone is public, and the specific repository that I’ve been talking about can be accessed here: <a href="https://gitlab.com/lander-team/lander-cpp" class="uri">https://gitlab.com/lander-team/lander-cpp</a> As you can see, the readme has charts that are always up to date. The <code>.gitlab-ci.yml</code> file contains all the build info, and you’ll likely be surprised how simple of a setup it is.</p>
|
||||||
<div class="sourceCode" id="cb1"><pre class="sourceCode r distill-force-highlighting-css"><code class="sourceCode r"></code></pre></div>
|
<div class="sourceCode" id="cb1"><pre class="sourceCode r distill-force-highlighting-css"><code class="sourceCode r"></code></pre></div>
|
||||||
<!--radix_placeholder_article_footer-->
|
<!--radix_placeholder_article_footer-->
|
||||||
<!--/radix_placeholder_article_footer-->
|
<!--/radix_placeholder_article_footer-->
|
||||||
|
Loading…
x
Reference in New Issue
Block a user