In our company, we’re licensing our product to several clients and the approach we have with them might vary based on the needs of the individuals […]
How we did it
We got some knowledge about Fastlane (link fastlane) and internally we have a robust team of devops which likes automate stuff with Jenkins.
On a first instance we dreamt to get the world and automate all the things (appropriate meme).
Then we’ve realised that considering the amount of client that we had at that time (plus the possibility to grow in terms of numbers of clients) it would have been better to start with little objectives. […]
Here comes the interesting part…
Internally, for texting about work, planning afterwork 🍻, sending nice memes, we use Slack (link to slack) (noooo really? 😂) and for us it’s the most used software after each specific one per component.
What tools have we involved in
- Docker (dependency in order to run a instance of the bot)
- Ngrock to get Jenkins accessible from outside (for the docker’s bot’s instance)
- .env methodology
- a spare macbook (possibly Pro)
- remote control / VNC (to get access from remote and check
How much time did we save by developing it
Hard to say, but I’ll make this point.
Given the process we have, every single ticket that needs to be tested, needs a build to be deployed to certain environment for a dedicated client (maybe two in some cases).
Previously, for every single ticket, we had to follow the steps written above.
So you can imagine…
- A build can be triggered directly from a QA guy by sending a message to the Slack bot
- Builds can be queued so there’s no need to wait one to finish before launching another one
I’d say - previously for each ticket, to follow those steps, we were taking from 30 mins up to 1 hour (depending on the complexity of the ticket and the number of client to test against).
From 0 to 2 mins - just the time for a good Italian ☕️
If something goes wrong, we’ll inspect what went wrong into the Jenkins build - but it’s just an isolated case.