Shipping Telescope 0.6, Planning 0.7

0.6 Release Requirements

I've just been going through the students' work for our 0.6 release of Telescope.  In a previous post, I threw down a gauntlet and told the team I needed to be able to dogfood their code a staging server.  Specifically, for 0.6 I said:

  • I have to be able to go to our staging server at http://dev.telescope.cdot.systems/.  If I can go to https://dev.telescope.cdot.systems/ instead, that's a bonus.
  • The site that runs there has to be a GatsbyJS app.  If the data it hosts comes from our GraphQL API, that's a bonus
  • I have to be able to login using our fake SSO service, and it needs to show me that I'm logged in somehow
  • The data hosted in the GatsbyJS app has to be live, and continually updated
  • I have to be able to read everyone's 0.6 blog post describing what they did, and what I need to mark

0.6 Release Realities

How did they do?  Really well, I think.  Over 95 commits went into this release, and here are some of the highlights.

First, https://dev.telescope.cdot.systems is up (notice the S in HTTPS).  Our staging server uses Docker Compose to build and server all of our apps.  We have an nginx reverse proxy to our node app, using automated Let's Encrypt certificate renewal to give us HTTPS.  A lot of this work was done by Josue and Miguel.  We also had an alumni drop in on the project unexpectedly and give us a PR to reduce our main Docker container from 1.9G to 250M!  Thank you Ray Gervais, you must have had a great teacher to know all this :)

Second, we now have a Gatsby frontend app!  A lot of people contributed to this, both with design and implementation work.  A huge thank-you to Ana who led design discussions and to Miguel, Cindy, Krystyna, and James who did a lot of the heavy lifting to get the app built.

Third, I'm able to login using SAML2 based Single Sign On.  James and I collaborated a bunch on this, with help from Josue to get it running smoothly on our staging server.  This is tricky stuff, and I'm glad we finally have it working.

Fourth, the data in our Gatsby app is live.  The data is currently using our REST API vs. GraphQL endpoint, and we'll work on that in 0.7. Having a staging box up now, with real data, has been amazing.  One amazing thing it has already enabled is that Cindy was able to get Zeit Now Preview Deployments working.  Every time one of our devs sends a PR, the Gatsby frontend gets built and hosted on Zeit.  It makes it so, so much easier to review frontend changes.  We also host master on Zeit, so it's easy to check on how things are working as we merge.  And since it pulls data from staging, we get to test it using real data.

Speaking of our backend, a number of our team members focused on backend app improvements, from Redis to REST to GraphQL to tests, and literally everything in between.  Thanks to Rafi, Calvin, and Julia for making sure that the data flows properly.

Fifth, I was able to mark this release by reading (almost) everyone's blog posts on our staging server running our app.  This dogfood tastes pretty good!

Some other interesting stories from this release:

  • We got hacked! I made some slides to show what happened in more detail, but the summary is that we kept hitting this weird bug on our staging box where Redis would go down every day.  It turned out to be hackers trying to sync with our Redis instance over the internet.  No harm done (we don't store any data that matters on that instance), and we got to discuss how to expose and protect ports with Docker.  I'm going to call this "a huge learning opportunity."
  • The different ways people like to work became more evident in this release.  Some of our team love using Slack and an "always-on" style of collaboration.  For others, this approach is distracting or impossible with other life commitments.  I see this mirrored in lots of open source projects and tech companies, and learning how to best include developers at both ends of the spectrum is really important.
  • We created an automated release process, and did our first proper release.  In the next release, this will also kick off a build.

0.7 Planning

Yesterday we met during our weekly Triage meeting to do a planning session for 0.7.  In the previous release, I picked what was in- and what was out of scope.  This time I wanted to share that responsibility across the team, and make sure we were hearing from everyone about their priorities and interests.

Release 0.7: James says it's easy!

Julia took excellent notes, which you can read for more detail.  During the meeting James repeated phrase "It's Easy!" so often that the rest of the team has nicknamed the 0.7 Release: "James says it's easy".  At a high level, here's what it needs to inlcude:

  • I should be able to log out of the app (SSO login works, but logout doesn't)
  • A push to master should deploy to our staging box automagically
  • We have a prototype UI for doing search
  • We can search for posts by Author
  • We have a prototype for an authenticated user to be able to Add a Feed from our frontend to the backend
  • Our Posts need to be better styled (images behave, fonts, etc)
  • The UI needs to look closer to our design
  • Our frontend app should make use of more Gatsby patterns and plugins

Luckily, James says this will be easy.  Let's find out!

Show Comments