I’ve really enjoyed trading with Robinhood (NO FEES) these last few months, but viewing some metrics in their web UI and mobile app take too many clicks. For one, determining my percent return requires three clicks for each Stock position. This is too slow when you want to be quickly informed on when to make quick exits.
The CLI Tool
Preferably, I wanted a quick and dirty CLI tool in Python to crunch these numbers for me. I ended up finding a great open source Python framework to interact with Robinhood’s backend API and decided to make some tweaks to it to support:
Streamlined Multi-factor Auth Login
Improved Security with credentials as environment variables
Calculate and display percent return on each position
Docker container build pipelines, tagging strategies, and CI/CD should go hand-in-hand.
Continuous delivery is difficult, but if your applications are containerized with Docker you’re moving in the right direction to make things easier! Containers provide a ton of flexibility and portability, but they can become a nightmare once you realize the pain of container management. One thing to make it easier is to have a standard container tagging strategy to provide common assumptions and vernacular amongst the team.
Docker container build pipelines, tagging strategies, and CI/CD should go hand-in-hand.
Do I Need a Better Tagging Strategy?
You might want to rethink your Docker Image tagging strategy if you don’t immediately know the answer to the following questions:
“What git commit hash of our app is currently running in production?”
“Which container version in our registry is currently running in production?”
Strategy: Release Candidate Lifecycle Tagging
The tagging method I find most attractive is what I call “Release Candidate Lifecycle Tagging”. The tag values should follow a flavor of release candidate terminology along the delivery pipeline similar to:
Build Stage
Tag Value
Development Stage
Initial Build
“<Commit Hash>“
“unstable“
“Alpha”
Passed Tests (Contract, Integration, Service)
“stable“
“Release Candidate”
Deployed to Production +
Smoke Tested
“live“
“GA” (General Availability)
What it Looks like in a Build Pipeline:
In the following example of a release of the app “app”, the current git checkout sha hash is “ff613f”. Initially building the Docker Image with the git sha hash is a pivotal piece that allows teams to know where/how to checkout the application for local or remote debugging of the exact version of the application.
A CI/CD build pipeline with incremental image tagging.
Taking it Further
Post-production Tags
With canary or blue/green deployments, additional tagging stages could be added incrementally to not only reflect that containers have made it to production, but that they reached levels of validity or traffic based performance metrics.
Retiring Images
Once an app image has been replaced by it’s subsequently upgraded version, the previous image needs to remain in the docker registry for an arbitrary amount of time in case a rollback is required. This can be accomplished by adding another tag after the image is retired like “retired-<RETIRED_DATE>”. Then, a reaping processes could take advantage of this new tag and only remove imagess that are X days old.
Credit
I want to give a shout out to Daniel Nephin, as his detailed and explanatory Github comments and issue discussions have led me to resolving many issues around Docker and container strategy.
Parker Gordon | Software Engineering 