Setup an easy way to deploy updated/changed/dev code to the RPi.

[harrisonCassar]

Description/Motivation

Currently, our desire to version control our software is actually hurting us when trying to perform testing on this changed code, as when we make a change in a local environment, we have no easy means of deploying that change to the RPi's copy of the code (currently, we've just had to manually edit the source code, which has been fine for smaller changes, but ideally not good in the long-run, and if we want to be more official/"professional" when making changes).

Possible Ideas for Implementation

Ideally, we'd love to have the RPi have a local copy of this AresSoftware repo, and work directly off of that (for now, just the main branch), having the RPi connect and re-pull the new changes/releases/dev branches to the repo whenever needed.

Or, perhaps in ADDITION (for use cases where we need to update the deployed code without having internet access, like when we're out in the desert), a means of plugging in a laptop into the RPi, and deploying it via some DevOps-related software, like Ansible?

To achieve this, we should research different means of connecting RPi to the internet (such as the UCLA Wifi options... do we have to go through authentication? do we have to use a mobile hotspot?). Is there an easy way to do this via command-line? Can we write a script to do this for us?

[harrisonCassar]

Was thinking a bit about this, and realized we could perhaps just limit the scope of our deployment to scenarios where we have a device connected to the same Internet-less network that the RPi under normal operation would be connected to (would love to perhaps have another network-less option, but the aforementioned limit on scope could be pretty easy to implement in something like Ansible very soon/right away!

Some nice things about Ansible as well:

• Easy to deploy to multiple systems with one command
  • Can also run other procedures with the same command but slightly different "playbook"
• Lots of open functionality for Ansible to do a lot of stuff
  • Can deploy code, run scripts on native and/or remote device, create new files/directories, build binaries, etc.
    • Would be nice once we start doing config-related stuff!

Just some thoughts... :)

[harrisonCassar]

Learn Ansible:

• Tutorial video:
  • https://www.youtube.com/watch?v=ZAdJ7CdN7DY&ab_channel=RedHat

[harrisonCassar]

With #36 merged, we likely want to have the following directory layout on the actual RPi (to which we deploy to, either when we're currently on the local RPi's copy of the repo OR when we're on a remote git repo, and want to copy to the RPi's local environment:

.
├── /etc/*.../
│   └── ...all necessary files, including:/
│       ├── telegraf/
│       │   ├── telgraf.conf
│       │   └── ...
│       ├── grafana/
│       │   ├── grafana.ini
│       │   └── ...
│       ├── *.service
│       └── dhcpcd.conf
└── ~/projects/
    └── ares_ground_systems/
        ├── build/
        │   ├── adc (compiled binary)
        │   └── server/
        │       ├── app.py
        │       ├── image.py
        │       ├── redirect.py
        │       ├── tc.py
        │       └── img/
        │           └── pnid.png
        ├── logs/
        │   └── ...
        └── AresSoftware/
            └── ...complete git repo contents...

(https://tree.nathanfriend.io/?s=(%27options!(%27fancy7~fullPath!false~trailingSlash7~rootDot7)~8(%278%27%2Fetc%2F*35-3all%20necessary%20files%2C%20including%3A0tele6Ctel6.conf9BCB.ini9*.service0dhcpcd.conf5%2C%27%2Fprojects5-ares_ground_systems0build4adc%20%7Bcompiled%20binary%7D4server4-app2image2redirect2tc2img4--pnid.png0logs9AresSoftware43complete%20git%20repo%20contents3%27)~version!%271%27)-%20%2005--2.py4-3...40-5%5Cn6graf7!true8source!9430B6anaC%2F4%01CB987654320-)

[harrisonCassar]

NOTE: Also consider how we can keep track of the version that is currently running (perhaps do commit hash that is deployed? or some deployment-ledger? @harrisonCassar has experience with this for another system). This will make sure that there is NO AMBIGUITY when we deploy code onto the RPi.

We can achieve this with a Deployment Ledger, which is appended to whenever we perform a new deployment. See this link-%20%2005--2.py4-3...40-5%5Cn6graf7!true8source!9430B6anaC%2F4%01CB987654320-) for an updated directory structure.

Also, this versioning should reflect in the logs directory too, perhaps by creating subdirectories based on the version number and/or commit hash.

[harrisonCassar]

We'd love to be-able to support "DEV" and "RELEASE" deployments to allow for two deployments to be "active" at one moment on our device, but for our initial functionality in this ticket, we instead only support the ability to deploy one version of GSW at a time onto the RPi, and consider this multi-version support whenever testbed/HITL setup begins.

[harrisonCassar]

Should also:

• Expose option to reset RPi among deployment (this SHOULDNT be the default, but just in case the user changes some important system file, like dhcp.conf).