
Ask HN: What are the small things that you’d automate in a software dev team? - prabugp
Typically there are a lot of IFTTT kind of tasks that we do as part of our daily lives - if we are working on a ticket, we create a branch of code, if we start the work, we mark the ticket as in progress, if a qa verifies all the test scenarios, we promote the deployment and so on. What would be your few things you would automate?
======
ajeet_dhaliwal
I think there’s so much that can be automated that isn’t, in every team I’ve
worked in. Almost everything other than non repetitive / creative processes
(design, coding, exploratory testing) should ideally be automated.

The reason it doesn’t happen most of the time is because other than automating
tests, where the benefit is super obvious, there’s no role or job assigned for
automating stuff specifically. It’s usually done as part of another job, such
as someone responsible for SRE. Automation doesn’t mean it’s set and forget,
it needs maintenance, updating, as processes change. People often automate
once, realise the process has changed, deem the automation a failure or
useless now, and because things need to work right away (to take care of other
deli erivables understandably) they don’t update the automation program but
rather continue doing things manually because of the instant success of
achieving it manually.

Automation takes upfront investment but the idea is it pays off over the long
term. If people think processes are going to keep changing and the automation
system is not flexible to deal with that it won’t happen. It needs a dedicated
person to do this and maintain this in larger teams.

You also need to figure out a way to demonstrate the value of you having taken
the time to automate something, especially if your management/leadership isn’t
clear on it. Shameless plug, I work on Tesults
([https://www.tesults.com](https://www.tesults.com)) for reporting test
results, and even though the primary aim of it is not to demonstrate the value
of automation it is definitely a byproduct/side-effect, customers have said
this.

Personally I’d focused on the obvious first: tests, build processes such as
getting code from repos for building, release artifact output. For mobile apps
for example have ipa and apk files automatically available for download by
manual testers. Then go onto less obvious things like automated sprint
creation for upcoming sprints in JIRA etc with their API. If in marketing,
perhaps social media automation for things their apis allow.

------
duncan-donuts
One thing I’ve wanted my team to automate is on boarding new microservices.
Being able to create a repo, generate the baseline configuration necessary and
deploy a container all within an action or two. The reason we haven’t is it
seems like a lot of work for a process that doesn’t happen very often (once or
twice a month)

~~~
prabugp
We wouldn't want it to be too easy to create a new microservice, would we? :)
Kidding aside, the closest we got to was a template service with a hello world
API which has all the basic configuration goodies in a repo. Anytime we need a
new service, we fork it, and start working on it in a few minutes. Wouldn't
that work?

~~~
shoo
> We wouldn't want it to be too easy to create a new microservice, would we?
> :)

i'll assume you're serious, so i agree. every time someone launches a new
service, there's an ongoing burden to maintain that service in production. so
maybe one heuristic would be to make the cost of launching a new service
roughly comparable to the discounted cost of maintaining that service for its
entire expected lifetime. then you could use the rule of thumb that if it
costs you X to build it, it'll cost you a second X to maintain it, so you
should only do it if you get > 2X value out of it.

see also:
[http://classicprogrammerpaintings.com/post/131118350394/army...](http://classicprogrammerpaintings.com/post/131118350394/army-
of-contractors-migrating-to-microservices)

------
quickthrower2
All local code should be backed up all the time, not just when you commit and
push. I’d love that for peace of mind.

Having meeting times from outlook appear on slack would be nice. One place too
look.

Maybe a slackbot for new starters. Not as a replacement for human interaction
but to aid in their induction.

~~~
prabugp
Outlook meeting times on Slack is an interesting one. Do you see it more like
alerts or someone else's meeting times in Slack that you can see?

~~~
quickthrower2
Alerts. The idea being that slack alerts are better. Outlook seems to alert
you but you can miss it, then the next day tells you about yesterday's
meetings. Plus looking at one thing for alerts is more likely to work.

