jules2689

6 ms·

1.
by jules2689 6y ago
The deploy queue usually gets to be a couple of "trains" deep which usually includes work from 4-10 devs. This represents a couple of hours. We have had issues with it taking too long, but this work I wrote about has improved that
2.
by jules2689 6y ago
a ton of internal debug logs :) We log all state machine transitions, poll the state machine to make sure it stays running, and do a ton of checks in the process. The debug button is a timeline of all of that. Basically trace-level logs
3.
by jules2689 6y ago
Yes there was. The change would have been quite a lot to do at once, and we aren't ready to safely add that circular dependency yet. We aren't done on this path, and this certainly won't be the last iteration. I suspect that
4.
by jules2689 6y ago
It's actually longer than 5 minutes. There is the duration of the 2% canary deploy where we start to see pick up of traffic, a 5 minute wait, then a 20% "deploy", and a 5 minute wait. All in all this comes out to around 10-15
5.
by jules2689 6y ago
It's mainly the simplicity of the deployment system as it's inline and visible, coupled with habit. It all actuality that is just what _can_ trigger the deploy, the actual deploy is based on an internal deploy application and depl
6.
by jules2689 6y ago
We monitor Datadog dashboards, exceptions, and other metrics mainly, as well as smoke testing the application
7.
by jules2689 6y ago
This is correct :)
8.
by jules2689 6y ago
There is some GitHub used, but as others stated we don't want to create a circular dependency on ourselves in case we deploy something that is broken.
9.
Using graph theory to inform changes to 1000 services(dev.to)
6 points by jules2689 7y ago|0 comments
10.
by jules2689 13y ago
http://docs.shopify.com/pos/about-pos/hardware/supported-har... Here you go :)