Setting up a Daily [CI] Email Process

This is a process I've used since I was a junior software engineer, now integrated into the Sprint mindset. It is especially useful if you have remote engineers.

Why

There is nothing in the world more boring than a serial status meeting, aka "staff". Everyone sits there while each person blathers on about their stuff, waiting for their turn to talk. At the same time, everyone wants and needs to know what the others are working on.

This process replaces the daily standup, and lets everyone know what's going on with everyone else.

How To on the Email

You have to lead on this. Every day, start an email and label it [CI] <Name> <Date>. The CI tells everyone its a checkin, the name is your name, and the date is the date. Do not address the email yet! This is a hack so you don't accidentally send it before the end of the day.

As you go through your day, keep a work log in the email as bullet points.

At the end of the day, review it, take the top item or 3 items, and put them at the top with the label Summary.

Address the envelope to your workgroup, and your boss.

How to Evangelize the Process

Soon, people will get used to the email. When they ask you why, you can tell them:

Serial Status Meetings suck.

It functions as an "I did this" list, so if I get interrupted a lot during the day, instead of going home feeling like I didn't accomplish anything, I see I accomplished quite a lot of little things.

It's gotten me several promotions because my boss always knew what I was doing, and it headed off problems because my boss would back me up.

Sample Email

Context: (this is raw and unedited except I removed some host names and replaced them with xxxxx, Glenn was my boss, kind of nervous)

Additional context: This was not a good day.

Summary

Rewound to where I was Saturday successfully.

Updated Dockerfile with some build tweaks for caltechy.

Ran into issues with apache config.

Sausage Making

checked on instance. I think my script to set the env variables didn’t work, so I just did each “export foo=bar” line one at a time in the terminal window and ran migrate again. This time I got complaints about not having enough privileges to read the database, solution to that is to change the environment variables to login as “root” instead of “labs”, so I’m going to do that.

Glenn reached out, he read yesterdays [CI] and was confused by the term “reset”. He wanted to use Google Hangouts, which meant resetting my password, because Google didn’t like my password. We’re crumpling tridents now. I explained that “ rewind” would probably be a better term, as I had the Caltech-Y branch running on a dedicated instance on Saturday, so if only I’d known I could have stopped there or gotten things working from there. He also didn’t get why I had problems installing “mysqlclient” since the docker build should be doing it just fine. Answer there is I’m not sure, as some of the yum packages are actually groups of stuff. All I did was add “gcc” by hand. Some discussion about long term goals, not sure what trade off we want between convenience and isolation, but that’s an involved discussion. For now, I’ll move forward with bootstrapping the Caltech-Y branch on a dedicated instance.

De came home from TJ’s with a car full of food, so I helped her with that. Her flowers and Sees came about then too. Much goodness.

Switched login to root, ran migrate. Complaint about cairo not being found, I think that’s a weasyprint, yum installed “cairo”.

Complaint about pango.

Found line in docker file that installed pango: “yum install -y libffi-devel pango gdk-pixbuf2”

Success! Migrate completed!

Ok, so I’m officially back to where I was Saturday. Perhaps a bit wiser, perhaps not. I still don’t get how to get there from here, so I need to go read the 3 articles from yesterday I didn’t finish.

Ok, I sort of get it now.

Each of the site_foo folders has a wsgi/production.py. That’s what starts the WSGI server and returns an application object for apache to interact with. There are foo.conf files in /etc/httpd/sites-available that do the apache config and mapping from ServerName to the right site/wsgi/production.py.

scripts/labs.conf, scripts/rpm.conf, scripts/admin-mightyant-com.conf are hard coded setups.

Built/pushed a scripts/caltechy.conf file based on rpm.conf. I have to put that in

I still don’t get how the environment variables get set, except the production.py files set a site.settings.production file via DJANGO_SETTINGS_MODULE before building the wsgi app. There’s also a weird line 52 in the run-production.py that extracts strings from /proc/1/environ. Presumably that’s some weird docker way of reading environment variables on an existing process but its not clear of the purpose.

Glenn asked me why this email was called a CI again, Googled “Sprint Check In”, discovered the formula isn’t Done/Blocked, it’s Done/Blocked/Tweak [here](https://teachingsprints.com/checkin-tool)

Worked on updates to “Dockerfile” to finish off adding xxxxx.businessengine.net to Docker builds in the future.

Redirected LB for xxxxx.businessengine.net to my new instance.

Still getting bad request! Meanwhile, getting a whole bunch of health checker requests from the ELB showing up in the logs.

Edited /etc/hosts to have an entry for caltechy.be.net, then did a curl directly. Got a real response, though maybe not the correct one.

Went and reviewed Route53 and ELBs. Looks like everything funnels to this one ELB: dualstack.labs-xxxxx.us-west-1.elb.amazonaws.com, aka “labs” in the EC2/Load Balancer console.

Since LBs now support Host header routing, Edited the rules on the “labs” load balancer to forward to a new target group: xxxxx-instances

Doubled checked on CodePipeline, it noticed my git changes, so it built but it failed to deploy because I’d deleted the “xxxxx” service.

Ok, time to debug locally on the instance by setting the host header for Curl. curl --verbose -H "xxxxx.businessengine.net" http://localhost/ Response doesn’t look xxxxx specific, it should look more like site_xxxxx/templates/index.vue.

So basically, apache isn’t setup right yet. Reviewing configuration files... It’s not including the sites-enabled config files correctly. That’s my bad, I was manually performing line 60 of Dockerfile and typed it wrong.

Ok, now I’m getting complaints that xxxxx.conf has a syntax error.

Bunch of errors now, mod_wsgi isn’t installed according to apache.

Installing mod_wsgi by hand using yum install mod_wsgi.

Errors are different now, apache complaining it can’t find /var/www/labs.xxxxx.com/.venv which is true, it isn’t there! Building it, activating it, and installing the pip requirements.

Ok, now getting whining about SECRET_KEY not being set. That at least comes from python.

Ok, getting 500 errors instead, that’s a weird sort of progress. Apache is spitting errors to the error_log with useful info and even a traceback. If I change the host header, I get the different hosts to track. Guessing I need to re-launch httpd with the env variables set correctly. Stack overflow points out I can do this via os.environ in production.py, I may have to do that. SO {More Complete Answer](https://gist.github.com/GrahamDumpleton/b380652b768e81a7f60c)

Well, good stopping point for today. Tomorrow I can build the necessary production.py file to preset all the environment variables for xxxxx, and I should be GTG.