The latest News and Information on DevOps, CI/CD, Automation and related technologies.
Every interaction with a Windows operating system begins with a successful boot process, paving the way for a stable user environment. Central to this process is the Boot Configuration Data (BCD) store, which houses the essential boot information that guides the system during the boot process. Managing this crucial data is the command-line utility BCDEdit, or “Boot Configuration Data Editor”.
When things go wrong, we’d all love the ability to go back in time, return things to the way they were, and fix whatever issues pop up at the start so they never happen in the first place. This is no different when maintaining complex microservices-based architectures. With any complex system, things are bound to go wrong from time to time.
Welcome to the first Signals Captain’s Log! My name is Robert, and I’m a recovering on-call engineer and the CEO of FireHydrant. When we started our journey of building Signals, a viable replacement for PagerDuty, OpsGenie, etc, we decided very early that we would tell everyone what makes Signals unique, and what better way than to tell you how we’re building it (without revealing too much 😉). Let’s jump in.
Sometimes, when building Runbooks in Orchestrator, it can feel like you’ve hit a dead end with no way to achieve the functionality or automation you require. For newer users, Orchestrator can be daunting because it is a completely blank canvas; there are no sample runbooks included or out-of-the-box automations. In addition, with a shift in focus to cloud automation, there is limited guidance and ‘how to’ advice available to help users.
