Table of contents generated with markdown-toc
My work on this can be found here: https://github.com/BradleyBoutcher/conjur-template This includes a basic start/stop script setup, and a "utility" file. The utility file includes helper functions meant to standardize and streamline the process of setting up and customizing a Conjur environment.
A few small things to call out:
- The process of adding policies to an already-running container is tricky, but can be useful in
some situations. Mainly because it's not easy to modify the docker-compose file for the quickstart before
running it. I set up a function called
addPoliciesthat takes a local path as an argument, and moves all files located in said path to the/app/policydirectory in the Conjur CLI container. - The utility file itself could be imported into other projects as a submodule, so it can be used in any project while still being subject to version control. I'm not sure if that's the best approach, as submodules add complexity to the git-workflow. I think "best case scenario" would be maintaining a shell script conjur utility project that is available to download on Mac and Unix through some package manager.
- Towards the top of the file, I declare a variable name for the Conjur Quickstart docker-compose
file, as well as a string called "conjur-compose", which passes the Conjur Quickstart to the
docker-compose calls with the
-fflag. While convenient, this isn't the best way to do it. It's built this way to work between Bash and Zsh shells, but would be better suited to be an alias or function of some sort. There's additional complexity as a function, as we'd need to accept an arbitrary number of arguments. And in the event of passing anexeccall intoconjur_compose, there'd be more string interpolation work to be done. Thus, I opted not to make it a function for now.
I keep a list of brews and casks that I downloaded during my time here. These can be installed by downloading the files found here, then running:
brew install $(cat .brews)
cask install $(cat .brew_casks)
Some tools, in particular ones in .brew_casks, may not be needed for your development environment, so be sure to read through them before installing anything.
There's several functions we use around here to
make certain work easier, such as oc_login, which helps us log into the openshift cluster. There's also a list I maintain of brews that are useful for new hires.
# Read logs for a given docker container
logs() {
docker logs -f $(docker ps --filter name="$1" --format="{{.ID}}")
}
# Open the Pull Request URL for your current directory's branch (base branch defaults to master)
function openpr() {
github_url=`git remote -v | awk '/fetch/{print $2}' | sed -Ee 's#(git@|git://)#https://#' -e 's@com:@com/@' -e 's%\.git$%%' | awk '/github/'`;
branch_name=`git symbolic-ref HEAD | cut -d"/" -f 3,4`;
pr_url=$github_url"/compare/master..."$branch_name
open $pr_url;
}
# Run git push and then immediately open the Pull Request URL
function gpr() {
git push origin HEAD
if [ $? -eq 0 ]; then
openpr
else
echo 'failed to push commits and open a pull request.';
fi
}
# Remove all orgs starting with "ci-org" from a cloudfoundry instance
function cf_clear_conjur_orgs() {
orgs=( $(cf orgs | grep ci-org) )
for org in ${orgs[@]}; do
cf target -o ${org}
cf purge-service-instance conjur -f
cf delete-org ${org} -f
done
}
# Log in to our pcf instance
function pcf_login() {
summon -p summon-conjur \
--yaml 'URL: !var ci/pcf/api-url
USER: !var ci/pcf/admin-user
PASS: !var ci/pcf/admin-cli-password' \
sh -c 'cf login --skip-ssl-validation -a $URL -p $PASS -u $USER'
}
# Log in to an openshift cluster
# argument #1 is the cluster (`current`, `next`, etc.)
# argument #2 is the environment (usually `dev`)
# Credit to @izgeri for making this!
function oc_login() {
cluster=$1
if [[ -z "$2" ]]; then
env="ci"
else
env="$2"
fi
summon --provider summon-conjur --yaml="
OPENSHIFT_URL: !var $env/openshift/$cluster/hostname
OPENSHIFT_USERNAME: !var $env/openshift/$cluster/username
OPENSHIFT_PASSWORD: !var $env/openshift/$cluster/password
" sh -c "oc login \$OPENSHIFT_URL:8443 --insecure-skip-tls-verify=true -u \$OPENSHIFT_USERNAME -p \$OPENSHIFT_PASSWORD"
}
The following aliases were useful, and my full list of aliases can be found here.
alias conjurops='docker run -it -v ~/conjurops:/root cyberark/conjur-cli:4'
alias mk='minikube'
alias mke='eval $(minikube docker-env)'
alias mku='eval $(minikube docker-env -u)'
# Commits all local changes, ammends your last commit, and force pushes
alias megapush='git commit -a --amend --no-edit && git push -f'
This code didn't get much attention, but it's in a decent enough place to be picked up.
The code was adapted from summon-conjur, so much of the framework for the project reflects that.
That being said, most of the scripts around installation should work, but need some tweaking.
Note: The blocker for this was the need for a live instance of azure to test against.
The repo can be found here: https://github.com/BradleyBoutcher/summon-keyvault
As we've started moving towards the agile process, we've found a few things that work for us, and a few things that don't. The agile process isn't a dogma we need to follow strictly, but it can help keep things organized.
Here's a few things I've found that work well for us:
-
Devs run standup, sprint planning, and grooming. This allows for more developer control and input over the work they're' actually going to do during a sprint. It encourages discussion and brainstorming where needed, which helps catch problems early. It also allows engineering and product managers to focus on their work, rather than having to switch contexts frequently.
-
Grooming of stories should happen during the course of the week, so our actual Grooming session can focus on setting up our board without needing to take a lot of time to create or rewrite stories. Stories made during planning or grooming are difficult to account for appropriately, and may turn out to be larger, smaller, or overall have unexpected issues.
-
Stories should have low point values. If it gets over four or five, it should be broken up.
-
There should only be one or two spikes during a sprint, with actionable work taking place during the sprint as well. This gives us time to complete demoable work, while also giving us breathing room to really dig into spikes. We can create follow up issues from that spike, which typically shouldn't be pursued until the next sprint. Sprints should have a specific goal, when possible, and we should take the time to make sure the work from a sprint is completed to a satisfactory level before context switching.
-
Spikes should be done as far in advance as possible before we approach the work for that milestone, so we have breathing room to plan out the work. Spikes almost always turn out to be larger than expected, and may even evolve during the period of "discovery and investigation". Always keep this in mind!
Mentoring new hires and interns is a significant part of any developers work, and is necessary for building strong teams. While mentoring is helpful for even high-level engineers, up to this point, I only have experience in mentoring those below my level. That being said, there are a few important things to keep in mind.
Most interns and new hires have experience in class related projects or labs, or previous internships. In addition to being a different "vibe", working in the professional industry requires different skills and practices. I describe this distinction as "domain knowledge vs industry knowledge". Most fresh engineers have plenty of domain knowledge - they can code whatever they need to code, they work well in groups, they can describe object oriented programming in their sleep - but they lack industry knowledge. For example:
- What makes a project "maintainable"?
- How can I leave useful code reviews? Should I not review work by "senior devs"?
- What terminology do we use at this company?
- How do I stay focused for an entire work day?
These things may be obvious to people who have been doing the job for a decade or so, but these are conceptual road bumps that can make it harder for interns or new-hires to onboard, and can make it harder for them to integrate effectively into the team.
While coding chops is important, interns in particular need to learn how to grow their career. These are skills you gain over time, and many engineers don't know how valuable this kind of information is. While we want the intern to be contributing to our code base, we want to help them to grow as well. New hires also may be exposed to new concepts after landing their first tech job.
For example, for new-hires:
- How much should I put into my 401k?
- How do RSU's work?
- How much should I pay in rent?
For interns:
- Should I negotiate a salary, or is it a fair wage?
- How do I know if a company will treat me well? What are the "red flags"?
- How can I get better at interviews?
- How can I improve my resume?
Again, engineers who have been living outside of college for a few years will know all these things, but interns and new-hires can feel out of place, and a bit lost at times. Making yourself available to answer career related questions, and guiding their growth towards working in the software industry, is a valuable investment in the next generation of programmers. This will help build trust, and make for a stronger team.
New hires and interns may not know how to, or have the confidence, to ask these questions themselves, so taking the initiative as an experienced full-time engineer goes a long way.
In summary; personal and professional growth are important for all new hires, and career advice can be incredibly valuable for people early in their careers. Just like a good contributing guide can improve contributions to a new project with exponentially positive results, a willingness to mentor in these ways will have a cascading effect.