Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Tools We Use To Stay Afloat

colloq.io

Post reply on HN
Print view View original

11–20 of 38 posts

Re: The Tools We Use To Stay Afloat

#11

Post by vmasto »

e1g wrote: post #5
kingbirdy wrote: post #3

The branch deploy sounds pretty interesting, I wish there was more detail on it than just a footnote

We do the same - it was surprisingly simple to implement - - CircleCI listens across all GIT branches and injects $CIRCLE_BRANCH into ENV - A build step populates a vhost template to point "$CIRCLE_BRANCH.qa.bofh.com" to "/var/www/$CIRCLE_BRANCH/current" - Another build step creates "manifest.json" with $CIRCLE_BRANCH and $CIRCLE_BUILD_NUM - The vhost config and the manifest are added to the release tarball/Docker im…

How do you handle the database? Do you reuse the one on staging or create a new instance with prepopulated data? If the former how do you deal with migrations and schema edits?

Re: The Tools We Use To Stay Afloat

#12

Post by awinter-py »

I wish this were an article about some hot new documentation tool instead of another misguided psalm to slack & kanban.

Making docs sexy would be a big quality of life boost for programmers and the people who love them (i.e. project managers and users of software).

Re: The Tools We Use To Stay Afloat

#14

Post by e1g »

vmasto wrote: post #11
e1g wrote: post #5

Earlier quoted context omitted.

We do the same - it was surprisingly simple to implement - - CircleCI listens across all GIT branches and injects $CIRCLE_BRANCH into ENV - A build step populates a vhost template to point "$CIRCLE_BRANCH.qa.bofh.com" to "/var/www/$CIRCLE_BRANCH/current" - Another build step creates "manifest.json" with $CIRCLE_BRANCH and $CIRCLE_BUILD_NUM - The vhost config and the manifest are added to the release tarball/Docker im…

How do you handle the database? Do you reuse the one on staging or create a new instance with prepopulated data? If the former how do you deal with migrations and schema edits?

Yes, the db has been the most challenging aspect for us. We have 3 situations -

1. "Common baseline". With a relatively stable product, most branches (as in ~51%) do not impact the schema. For testing / QA purposes, these share one central QA db and pollute each out. Turns out, a lot of the times this is quite ok because the PR is about how the data is displayed, or improved logging, or UX change, or a security layer or anything else other than core domain knowledge - they don't care for the data that much.

2. "I'm special". Some branches do modify data (whether the format or the structure). To handle these, the manifest.json file has an option to request a separate database. If present, the rollout script will do "pg_dump + copy" of the shared staging DB, and duplicate it into "qa_$BRANCH", then update the config file (or .env for Docker) with the appropriate connection value. Additionally, it will all *sql files in a dir specified in manifest.json against the clone DB. This is done on every release, which does get annoying by resetting the qa data (we could add another manifest switch here I). On the upside, it forces you to codify all data migration rules from the start.

3. "I am very special". Some changes transform data in a way that requires business processing and cannot be done with easy SQL. Sorry, out of luck - we don't automate special cases yet. The developer has to pull the QA database to localhost, do his magic, and push it back. Not ideal, but hasn't caused any problems yet. If ain't broke...

Re: The Tools We Use To Stay Afloat

#15

Post by anselmh »

cpr wrote: post #2

Matches more or less what we do as a 4-man team. I'm curious why they used appear.in instead of Slack's audio/video conferencing? The latter is too new?

It’s a combination of a few things. First, when we started doing calls together Slack calls weren’t available yet for multiple people.

In our experience, Slack calls often fail for a variety of reasons. Other than that, we don’t want to shift too much data to Slack and since it’s pretty unclear how their calling technology works and appear.in uses WebRTC, we rather use another service here than a service where we don’t know much about it but only that calls aren’t too reliable. But as said, we haven’t bothered to check the group-video calling yet there. We’re pragmatic. Appear.in works in any browser (Slack calls don’t) and therefore… why should we change a well working system?

Re: The Tools We Use To Stay Afloat

#16

Post by anselmh »

dbg31415 wrote: post #9

ZenHub is free for teams under 5 people. And it's great. * ZenHub - Agile GitHub Project Management || https://www.zenhub.com/ Also I use a tool that keeps labels in sync across GitHub repos. * github-label-sync || https://www.npmjs.com/package/github-label-sync Harvest for time tracking. * Simple Online Time Tracking Software - Harvest || https://www.getharvest.com/ Red Pen for annotations. (Does't integrate with an…

Thanks for the list, it’s quite good! However, our point is to not use third-parties for things where we don’t need it.

The point of the article is to show that you can use Github solely for project management without a third-party service.

But I completely agree with you: If you don’t like the little extra-work we do to achieve that with just github.com, it’s probably right to add another tool like ZenHub or waffle.io on top of it.

Making your toolset work for your team is the most important thing. For us, it’s enough — and maybe for a few others as well. That’s why we shared our approach :)

Re: The Tools We Use To Stay Afloat

#17

Post by sejiss »

vmasto wrote: post #11
e1g wrote: post #5

Earlier quoted context omitted.

We do the same - it was surprisingly simple to implement - - CircleCI listens across all GIT branches and injects $CIRCLE_BRANCH into ENV - A build step populates a vhost template to point "$CIRCLE_BRANCH.qa.bofh.com" to "/var/www/$CIRCLE_BRANCH/current" - Another build step creates "manifest.json" with $CIRCLE_BRANCH and $CIRCLE_BUILD_NUM - The vhost config and the manifest are added to the release tarball/Docker im…

How do you handle the database? Do you reuse the one on staging or create a new instance with prepopulated data? If the former how do you deal with migrations and schema edits?

We have a job every morning that clones the current production db instance and then deploys it onto a staging instance. All PRs with schema changes will be applied to this instance when merged. If something goes wrong, we just redeploy the saved image.

Re: The Tools We Use To Stay Afloat

#18

Post by hobofan »

dbg31415 wrote: post #9

ZenHub is free for teams under 5 people. And it's great. * ZenHub - Agile GitHub Project Management || https://www.zenhub.com/ Also I use a tool that keeps labels in sync across GitHub repos. * github-label-sync || https://www.npmjs.com/package/github-label-sync Harvest for time tracking. * Simple Online Time Tracking Software - Harvest || https://www.getharvest.com/ Red Pen for annotations. (Does't integrate with an…

Time tracking seems very microcontrolish for such a small team, and doesn't really seem worth the overhead. If the team includes freelancers, that's of course a different thing.

Re: The Tools We Use To Stay Afloat

#19

Post by hobofan »

awinter-py wrote: post #12

I wish this were an article about some hot new documentation tool instead of another misguided psalm to slack & kanban. Making docs sexy would be a big quality of life boost for programmers and the people who love them (i.e. project managers and users of software).

Best tip for docs in small teams: Have a server running in the local network that pulls the latest develop branch, renders it and serves it on the network for each project. For microservices I would recommend API Blueprint, for normal libraries, whatever is the language standard. Really cuts down the friction of getting to the docs, since you don't have to do all those steps on you local machine anymore whenever you need to access the documentation of an internal project.

Next best thing would be building Dash docfeeds for internal projects.

Re: The Tools We Use To Stay Afloat

#20

Post by awinter-py »

hobofan wrote: post #19
awinter-py wrote: post #12

I wish this were an article about some hot new documentation tool instead of another misguided psalm to slack & kanban. Making docs sexy would be a big quality of life boost for programmers and the people who love them (i.e. project managers and users of software).

Best tip for docs in small teams: Have a server running in the local network that pulls the latest develop branch, renders it and serves it on the network for each project. For microservices I would recommend API Blueprint, for normal libraries, whatever is the language standard. Really cuts down the friction of getting to the docs, since you don't have to do all those steps on you local machine anymore whenever you…

hadn't heard of API blueprint -- pretty cool.

in addition to tools for documenting interfaces (i.e. APIs), I'm interested in tools that document behavior (both desired & observed) and integrate it back to codebases.

In type safety terms, this is like the difference between function signatures that verify inputs & outputs vs something like coq/TLA that can verify more advanced properties of your program.

Configuration is particularly difficult to document in 2017 -- if you solve that problem you fix a lot of migraines.

Post reply on HN