Azure Logic Apps are pretty amazing. You can quickly create elaborate workflows, integrating with many of your favorite Microsoft applications and develop your own custom connectors for 3rd party systems and platforms.
Over the years, I have coached and researched dozens of scrum teams to adapt to “real world” scenarios. Some may call them anti-patterns or some may call them “not scrum”-- but that is okay too because sometimes we have to work with what we have and still find ways to be successful.
The very notion of economies of scale arose during the early industrial age but unfortunately is still prevalent in many industries, including software development. However, that has changed with DevOps but it still isn’t obvious otherwise I would not come across customers that still work in this paradigm.
Unfortunately, many enterprises have multiple organizations and projects in their portfolio and merging them into a single project can seem a daunting task. While there are tools out there that can help, there is no “Single Tool To Rule Them All”.
The thing I was interested in recently was deploying to the smallest and least expensive dev/test instances of the various services in order to keep the cost down. Since this was just for demo purposes and I would be the only one talking to the bot, I didn’t need the capacity and scale of the default install.
This setting allows developers to configure the level of deoptimization suitable for their apps. To enable deoptimization, be sure to enable Snapshot Debugger call stacks and local variable support from the Application Insights configuration page.
if you want to change something, never immediately assume that current conditions are immutable. If you’ve never discussed the possibility to change, you cannot know whether others – your partners, customers, teammates, or managers – would resist, or the reverse – enthusiastically gush and support the change.
How do you deal with the fact that the developers in your organization cannot or will not own the process of delivering into production? How do you deal with the fact that your operations engineers cannot or do not fully understand the software to which they have been given stewardship?
At this point we were five plus years into a local transformation that was underappreciated and overlooked by the global IT organization. The frustration was high and the hope was waning. For me this became my motivation to start a journey to understand why some organization can adopt DevOps strategies successfully and other struggle.
By removing or reducing tribal knowledge from projects and teams, organizations set themselves up for success in an ever-changing landscape (exponentially changing). In other words, you can add to your DevOps culture (or create one) simply by subtracting the bad habits and behaviors.
