Skip to content

Top Best Ask Show New Jobs

Ask HN: What are the small things that you’d automate in a software dev team?

6 pointsprabugp7y ago9 comments

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?

9 comments

9 comments · 3 top-level

duncan-donuts7y ago· 3 in thread

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)

prabugpOP7y ago

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?

shoo7y ago

> 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...

quickthrower27y ago

A github repo with a docker file and appveyor.yml or similar, then fork it would be most of the job done. You might need to manually create a new appveyor project each time though.

quickthrower27y ago· 3 in thread

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.

protonimitate7y ago

I haven't used these myself, but there seems to be a few options:

https://slack.com/apps/A0PCRAVL5-meeting-bot

https://zapier.com/apps/office-365/integrations/slack

https://slack.com/apps/A0G51AT60-meekan-scheduling

prabugpOP7y ago

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?

quickthrower27y ago

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.

ajeet_dhaliwal7y ago

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) 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.

j / k navigate · click thread line to collapse