
Tee-Ball - eitland
https://blog.cjeller.site/tee-ball
======
superbaconman
The list of crap to consider when deploying code is disgusting: Do you ship a
single binary or do you copy a boat load of language files over? Do you use
your languages special packaging tool or do you use something like rpm? How do
you handle dependency conflicts? Where on the box do you store your files?
What should the default config look like? How do I populate my prod config?
What about app install scripts? Do I use puppet or ansible to manage packages
and configs? How do I know if my application stops running? What if it hangs?
Should I put my app behind nginx or apache? How do I configure my firewall?
What about backups? Is your SSL cert up to date?

~~~
echelon
> The list of crap to consider when deploying code is disgusting

This is why we get paid enough that we can retire in a mere decade.

> Do you ship a single binary or do you copy a boat load of language files
> over?

Rust or Go? Single binary. But you should ship containers regardless of
language and just not care.

> Do you use your languages special packaging tool or do you use something
> like rpm?

DO NOT USE THE HOST PACKAGE MANAGER. Version and lock your dependencies.
Vendor them. Don't get tangled up in the OS. That'll double the trouble. Then
build and ship containers. Don't ever run bare metal unless you want to be
tied to it as a design contract.

> How do you handle dependency conflicts?

A monorepo helps tremendously. You seldom deal with dependency issues, and
every bump is handled by one person once in most cases. But people tend to
hate these for some reason. I happen to think they work even for small orgs.

> Where on the box do you store your files?

Firstly, use containers. But as for where to place them, the homedir or /data
is perfect. But it doesn't really matter that much if you make a single choice
and stick with it across your apps.

> What should the default config look like?

Like development.

> How do I populate my prod config?

prod = development, but overrides for the prod topology. Perhaps this varies
wildly for apps that use many sharded databases. This is the nature of our
work.

> What about app install scripts?

Docker / K8S. Don't bake them into the runtime lifecycle if possible.

> Do I use puppet or ansible to manage packages and configs?

Version control your config. You won't have secrets in them.

> How do I know if my application stops running?

Metrics + PagerDuty

> What if it hangs?

Metrics + PagerDuty

> Should I put my app behind nginx or apache?

Rust or Go won't need this. Swift might work too. Ruby and Python, maybe.
Sounds like a lot of work. You can launch it as a sidecar or DaemonSet,
perhaps. I shy away from scripting languages that need to be load balanced.
You're stretching a solution beyond its limits, and there are modern languages
and platforms that won't need this.

> How do I configure my firewall?

Envoy, Calico. Default policies to DENY all except what you carve out.

> What about backups?

For your databases, file uploads, and last few weeks of production builds.

> Is your SSL cert up to date?

Monitoring and paging helps here too.

------
abeyer
Isn't the author just asking for a shared hosting plan? That used to be the
default thing that everyone started with. (well, unless you had a shell
account with a `public_html` already)

They aren't the trendy new thing, but they're more than adequate for most
beginner projects. They work quite well even up to pretty reasonable scale for
SPA frontend-focused apps, and "deployment" consists of `scp` or a friendly
gui client.

~~~
lonelappde
repl.it, a YC company, is tee ball for deploying software.

------
vparikh
Well most of us older devs had what could be called "Tee-Ball" for software
developers. Back in the day it was generally referred to as the home computer.
You had multiple kinds, that stressed different priorities - like the
Commodore 64, Atari 800 series, Apple II etc. Pick your favorite.

The unifying concept was they were simple machines, with a basic feature set.
Came well documented and when you turned them on they dumped you into a BASIC
shell.

Everyone typed in something to the effect:

10 print "Hello"

20 goto 10

Run

No compilers, editors, linkers, deployment, security rights. Nothing. Just
turn it on and type simple stuff. Screw up the machine -- just power on, power
off. Bam - you get to the default stable state to try again. Get into the
complexity when you are ready and willing to deal with it. Brilliant.

Kids today don't have that.

------
cma
>There is no assistance like a sticky ball or glove.

Maybe no kids leagues use it, but there are sticky balls and gloves using
velcro that are used in informal play, usually in indoor gyms and/or just for
little kids playing in the backyard.

------
dustingetz
Let's refactor the posed question to: what natural forces circumstances and
history of evolution have led to the current situation?

MS Access (1992) and Visual Basic (1991) could be pitched as a Tee-stand for
software. Why didn't they take over? What happened in the 90s? The world wide
web. Microsoft was over here playing desktop tee-ball while web technologies
ate their lunch.

It takes time to smooth out a software stack, but it keeps getting disrupted
every ten years.

~~~
Crinus
Well, they did took over when it came to desktop. But in the 2000s the web
became popular as a target for applications so their desktop dominance wasn't
the only thing that mattered.

However in their niches MS Access and Excel (VB not anymore but that was
because Microsoft forcefully killed it, not because the developers that used
it decided by themselves to move away from it) are still dominant (in fact so
dominant that they overflow from these "niches" \- see how many stories of
Excel VBA doing things that weren't "supposed" to be done in Excel).

------
pacaro
Somewhat off topic, but is there any other stick-and-ball game (other than
baseball and it's derivatives) where the fielders use a mitt/glove?

The other related sports (including baseball's origin sport 'rounders') all
require barehanded fielding (AFAIK), with the occasional exception on a
specialist backstop (e.g. the wicket keeper in cricket)

~~~
maw
The closest I can think of is a trapper, worn by a goalie in hockey. See
[https://en.wikipedia.org/wiki/Trapper_(ice_hockey)](https://en.wikipedia.org/wiki/Trapper_\(ice_hockey\))

------
jyrkesh
For me, tee-ball was writing C into the Pico text editor, gcc'ing it, and
running it.

Pitching and hitting was the first time I ever opened an IDE. Now I know my
way around, but the learning curve on firing up VS or Eclipse the first time
(can't remember which it was): holy crap.

------
will_pseudonym
Naive question - What makes deployment more difficult than development?

~~~
cobbzilla
The same thing that makes writing a grade-A essay harder than verbally
explaining your idea to the professor. Both require slinging words with
meaning, but the stakes are higher for the written paper: it needs to stand on
its own and “defend itself”.

