Ask HN: What are the small things that you’d automate in a software dev team?
1–10 of 10 posts
Re: Ask HN: What are the small things that you’d automate in a software dev team?
#2Re: Ask HN: What are the small things that you’d automate in a software dev team?
#3Having 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.
Re: Ask HN: What are the small things that you’d automate in a software dev team?
#4One 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)
Re: Ask HN: What are the small things that you’d automate in a software dev team?
#5All 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.
Re: Ask HN: What are the small things that you’d automate in a software dev team?
#6One 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)
Re: Ask HN: What are the small things that you’d automate in a software dev team?
#7One 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)
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?
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...
Re: Ask HN: What are the small things that you’d automate in a software dev team?
#8All 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.
https://slack.com/apps/A0PCRAVL5-meeting-bot
Re: Ask HN: What are the small things that you’d automate in a software dev team?
#9All 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.
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?
Re: Ask HN: What are the small things that you’d automate in a software dev team?
#10The 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.