If you’re a developer experimenting with AI tools like Copilot, Cursor, or Claude, you’ve probably seen both ends of the spectrum: blazing-fast progress… and mysteriously broken code.

That's because AI can be an incredible force multiplier, but only if you use it the right way.

In this edition, I’m sharing 10 habits and principles I’ve picked up from building real products with AI tools. These aren’t abstract theories or copy-paste workflows, they’re lessons learned the hard way, after shipping features, breaking things, and figuring out what actually works.

Let’s dive in.

1. Know How LLMs Think (Because They Don't)

LLMs (Large Language Models) like GPT or Claude generate code by predicting the next most likely word or token—just like a hyper-advanced autocomplete trained on billions of code and text examples.

Imagine you type: “The quick brown fox jumps over...” The model fills in: “the lazy dog.” It’s not thinking, it’s guessing what’s most likely to come next based on patterns in its training data.

When you ask for code, it’s the same. The more details you give (context, requirements, style), the more likely you’ll get something useful and accurate. If you’re vague, you’ll get a generic or even wrong answer—because the model is just picking from what it’s seen before, not truly understanding your intent.

But the amount of context you can provide is limited by the “context window” of the model (how much text it can process at once). If you try to include your entire codebase, it will start forgetting details from earlier in the conversation.

But the one thing you should understand here is that prompts are an important skill—you shouldn’t expect an LLM to provide good answers with vague requirements. It’s not magic; your results depend on how you ask.

More details on how LLMs really work and how to master context will be in the next edition.

2. Zero Trust Coding: Always Review the AI’s Work

As I said earlier, the better the prompt the more accurate the results, but how can you be sure that you gave the best prompt that provides the best result? Even more, what if there is no result but the LLM still provides incorrect ones while being sure they are valid?

No matter how good the suggestion looks, always review every line, especially for anything beyond throwaway code.

Why? As I shared last time: I once asked Copilot to remove a C# entity from a microservice. It “helped” by deleting a database table I didn’t mean to touch. We lost QA data, and over 50 people were blocked for hours. The AI did what I said (and more), because I didn’t review the changes closely enough.

Practical Advice:

• Treat every AI commit like a PR from an overeager junior dev.

• Use git diff to inspect all changes, especially deletions and multi-file edits.

3. Iterate in Small Steps

Don't try to generate an entire feature from one prompt. Break your work into multiple steps: focus on a small piece at a time, make sure it works, and always commit or stage before moving on. This way, you always have a clean, working state to return to. Plus, if you break something, it’s easy to pinpoint what changed or roll back to your last safe spot.

Example: Let's say you use this prompt: “Refactor the OrderService class and fix performance issues”. You might end up spending hours talking with AI and getting nowhere, kind of like this guy:

Minimize image

Edit image

Delete image

Instead, you should do it like this:

Step 1: Stage all your changes with git (git add .*)*

Step 2: Use a focused, targeted prompt for just one small change. For example: "The OrderService class has many functions that use the same code for authentication. Move that code into a helper function and call it to prevent duplication.”

Step 3: Review the code, at this stage you have 3 options:

• Code is flawless: continue to step 4

• Code needs small changes from your part: make the changes and continue

• The code has too many issues: just reset the changes and try again with a different prompt, this time making the necessary adjustments so that it doesn't end up in the same state. For example, if the duplicated code is removed but the helper function does something completely unrelated from what it was doing before, then say "T*he OrderService class has many functions that use the same code for authentication. Move that code into a helper function and call it to prevent duplication. **The helper function should keep the same logic as the duplicated code that we remove".* Send the prompt and go back to Step 3, if you do this 2-3 times and it doesn't work, just do the refactoring yourself! Worst case: you’ve lost 30 minutes experimenting with AI instead of spending a day doing the refactoring manually, so it’s not a waste of time in my opinion.

Step 4: Once you have code that you want to keep, stage your changes. Sometimes the code might be 99% perfect, and you just want a small tweak (like updating the text of a button), but the AI updates every button in the app instead. If this happens, reverting manually could take ages, but with git you can instantly roll back and get back to your 99% working state. Staging your changes early and often is the safety net that saves you from these moments.

Step 5: We'll now use this prompt: “The ReadOrders function takes too long and I know the query for retrieving the orders is the main issue, give me at least two ways it can be improved.”

Step 6: You should now have at least two options for improving the performance, choose one or continue the conversation until you find an acceptable solution. If the AI is unable to provide a solution, then maybe you need to give it more details. For example, the LINQ query might be perfect so the AI can't give any more solutions, but if you provide the database structure in the context it can suggest creating an index. That's why it's important to give as many details as possible.

Step 7: Continue this cycle for each sub-task. With this approach, something that used to take a day or two might be done in 30 minutes (on a good day!).

The key is to work incrementally, stage your changes often, and never be afraid to reset and try again. This habit saves you hours of debugging and gives you confidence in every step.

4. Play to AI’s Strengths

LLMs truly shine when you use them for what they do best: generating and summarizing text. Their sweet spot includes:

• Writing Documentation: Give the AI a few bullet points or a rough outline and it can produce a professional, typo-free README or even detailed tickets for Jira. You’ll be surprised how much time you save and how much clearer your docs become.

• Generating Scripts: Whether you need a bash script, a one-off migration, or a quick automation, AI is fast, reliable, and generally accurate for these bite-sized, isolated tasks. Scripts are usually just a single file, without hundreds of dependencies spread across a codebase, making LLMs ideal for generating/changing scripts quickly and safely.

• Brainstorming: Stuck on naming, architectural choices, or edge cases? Use the LLM to quickly list pros/cons, generate alternatives, or unblock your thinking, then refine the results with your own expertise.

LLMs were designed to generate natural language, so let them handle the boilerplate and wordsmithing while you focus on building and reviewing.

5. Know Your Tool Inside Out

Each AI coding tool has its own advanced features. It’s like moving from Notepad++ to Visual Studio, but there you only use the Visual Studio text editor. You're literally missing on 95% of its capabilities if you're doing that!

Most devs only scratch the surface of what these AI tools can do by treating them like "chat with AI" tools, they then end up missing out on real productivity gains. For example:

• Cursor: Earlier I mentioned how I use Git to stage changes between prompts, but did you know that Cursor lets you instantly undo your last set of changes done by AI?

• Copilot: You can add a copilot-instructions.md file to your repo to give additional context for the work it does in that repository. Say your team uses XUnit and NSubstitute for tests, but each time you ask it to write a new test class it uses MSTest and Moq. Instead of mentioning these libraries in each prompt, just update your copilot-instructions.md file with this: “My unit tests are written with XUnit and I use NSubstitute for mocking.” Copilot will then use your stack by default, letting you focus prompts on what to test.

• PS: Cursor has "rules" that work the same way as copilot-instructions, and are a bit more advanced, but I'll talk about this in a later edition.

It’s worth taking a few minutes to learn these features. You’ll save yourself hours (and frustration) in the long run, and your AI generated code will be much more accurate.

6. Why Mainstream Stacks Work Best with AI

AI models are only as good as their training data. This doesn't mean you should switch to React just because it's more popular than Blazor. On the contrary, you should use the technology where you're most experienced, so you can catch issues faster and review the AI’s output with confidence.

However, if you sometimes struggle to generate good code for a less popular technology, now you know why: there just isn’t as much high-quality example code for the model to draw from. You can still get good results, but you might need to invest more time in better prompts and context.

On the other hand, if you’re a CTO or tech lead deciding on the stack for a new project, consider that your team will generally get better AI-assisted results with more popular technologies. If fast onboarding and high-quality AI suggestions are a priority, investing in a mainstream stack pays off, not just for you, but for anyone using these tools on your codebase.

7. Enforce Restrictions Early

Turn on strict modes in your language. For example:

• C#: In your .csproj, set TreatWarningsAsErrors to true.

• TypeScript: Enable strict mode.

• And so on...

Why? These guardrails force both you and the AI to write safer, more robust code, and make it much easier to spot potential issues. For example, in C#, I often see warnings for possible NullReferenceException which most often come true. Some devs ignore these, but I always double-check, is this warning real? By doing this, I’ve almost eliminated these errors in my projects, when before they were my most common runtime bug.

Another “restriction” is writing unit tests. If you ask the AI to modify code that’s covered by tests, you can immediately run them to see if it works—no guessing, just feedback.

8. Use MCP servers

I love using MCP servers, they’ve become essential in my workflow. To give you one example, in my current project I use Azure Boards, and the MCP server made onboarding ridiculously easy. For example, if I’m assigned a ticket with ID #1234, I just use a prompt like:

“Read ticket #1234, analyze the codebase based on the description, and determine what changes need to be made. Then provide a summary.”

Remember how long it used to take to do even the simplest task on a new project? You’d have to hunt for the right files, piece together context, and hope you didn’t miss anything. Now, AI can instantly show you where to start and what to look for. You still need to review and understand the code yourself, but with AI guiding you, you get a huge head start.

Although it's a new concept, MCP servers are very popular and now it's very easy to find (or create) one for basically anything. Azure, Github, Todoist, etc.

Here are some places where you can look for MCP servers:

https://docs.cursor.com/en/tools/mcp

https://mcpservers.org/

https://mcp.so/

9. Structure Your Codebase for AI Agents

If you want the best suggestions from AI tools, make it easy for them (and your teammates) to find the right files and understand your project structure. The more predictable and well-organized your codebase, the better AI agents can navigate and make smart recommendations.

Best practices include:

• Use clear, consistent naming conventions for files, classes, and functions. (e.g., OrderService.cs vs. svc1.cs)

• Organize code by feature or domain, not just by layer or type.

• Keep related code together, and avoid giant “miscellaneous” folders.

• Maintain up-to-date README files and project documentation at the root.

• Use standard folder names (src, tests, docs, etc.), so AI agents instantly know where to look.

This isn’t just for the AI—future you (and your team) will thank you, too. But with an organized repo, AI tools can connect the dots more easily, suggest relevant changes, and avoid confusion.

10. Stay in the Loop

AI tools evolve fast... sometimes too fast.

I've bookmarked new tools or articles only to find them outdated a month later. What used to take years to change now happens in weeks. Keeping up isn’t optional if you want to use these tools effectively... but let’s be honest, it’s also exhausting.

You already have a full-time job. Staying current often means using your own time, and most of what’s out there is either noise or hype. A lot of popular content leans hard into vibe-coding and “AI will replace devs” takes. Not because it’s helpful, but because it gets clicks.

That’s why I write this newsletter: to offer a more grounded, practical perspective. No hype. No fear. Just real workflows that work in production.

How to stay up to date (without burning out):

• Follow tool changelogs and release notes

• Subscribe to developer-first newsletters (like this one)

• Join communities around the tools you actually use

Stay curious, but filter hard!

That’s a wrap for the second edition of The Copilot’s Log. I aimed to keep it concise while giving you enough to build a solid foundation. In upcoming issues, I’ll dive deeper into each of these practices, with real examples and workflows you can try.

If this was helpful, there’s more where it came from—subscribe to The Copilot’s Log and follow me on LinkedIn for weekly tips, walkthroughs, and lessons from the field.

PS. Beyond writing this newsletter and my day-to-day job, I help dev teams level up their AI workflows through hands-on training. No buzzwords, no slides, just practical sessions focused on using tools like Copilot, Cursor, Claude Code or Windsurf effectively in production environments.

If your team is adopting AI coding tools and wants to get it right from the start, reach out. I’d be happy to help.

No hype. No fear. Just honest stories and practical takeaways.

To kick things off, I want to share two short stories from the past 9 months. These moments will give you a feel for what this newsletter is all about.

Story #1

Todoist's CEO just teased a new feature on his Twitter page. My app, Task Analytics for Todoist, is a power-up that adds features their platform doesn't offer. So I thought it would be cool to try to build the same feature before they launch it. I fired up Cursor, crafted the initial prompt, and in less than two minutes I had a basic version of the calendar that was 100% functional from the start without requiring any changes from my part. I pushed it to prod, recorded a video about it, and replied with that video in the same thread.

The result? 21 new users and over 300$ for 5 minutes of vibe-coding.

Part of me was thrilled. Another part thought: if AI can do this so easily… what happens to my career as a developer?

Story #2

November 2024, I was tasked with removing endpoints related to an entity from a microservice. The job seemed simple enough for AI, so I opened VS Code and asked Copilot to remove all the code that used that C# entity (services, controllers, repositories, etc.)

Less than a minute later, over 50 files had been changed. I scanned the diffs in GitKraken, but not too carefully. Everything looked clean. The service still ran, smoke tests passed, and I pushed the code. A colleague gave it a quick review, and the PR was merged.

Two days later a table gets deleted from our QA database. I thought it might be related with my changes, so I started to go through the latest pull request. Indeed, someone created a PR with a migration that had the "DROP TABLE" command, but they insisted they haven't removed that entity. I then looked at my PR and found that I was the one who removed it. Turns out that Copilot decided to delete a little more than I requested, and I missed it because I haven't reviewed it carefully.

That’s how I learned a hard lesson: AI can make decisions you didn’t ask for, in places you least expect, and if you’re not watching, those decisions can have severe consequences.

Luckily for me, this didn’t reach production. But it blocked more than 50 people from working on that environment for over two hours while the issue was found and the data was restored.

Why I'm Writing This Newsletter

Over the past few years, I’ve used AI tools extensively to boost my productivity, and it’s made a real difference in my career. AI has helped me deliver more in less time, stay steady in a volatile job market, and even launch my own app, where it filled in as a kind of co-founder... handling front-end work, marketing copy, and more.

But for every success, I’ve had failures too. And I want to share both. Openly.

I’m pragmatic about AI. I don’t believe it’s a silver bullet, and I don’t think we should fear it either. That probably means I won’t attract as many readers as those hyping vibe coding or those warning that AI is killing our craft. But I’m okay with that.

This newsletter is for devs who want to get better (not just faster) with AI. So, in this first edition, I want to talk about exactly that: Vibe coding vs AI-assisted development.

Vibe-coding

Vibe coding is a software development approach where developers heavily rely on large language models (LLMs) to generate code from natural language prompts. It involves giving general, high-level instructions to the LLM, which then produces the working code. This method aims to accelerate development and make app building more accessible, especially for those with limited programming experience.

Does this definition sound too good to be true? That's because it really is too good to be true, at least at the moment I'm writing this newsletter.

This approach has its pros and cons, and that’s why I wanted to share both success and failure stories. Relying on AI to write code without truly understanding or reviewing it can lead to serious consequences. I’m not gatekeeping here—vibe coding can be a great way to dip your toes into programming. But using it as your only tool to build and ship products? That’s where things get risky.

Why Vibe Coding Can Be Risky

Vibe coding is becoming popular among folks with little to no dev background. While I admire the entrepreneurial mindset, this can be dangerous when taken too far.

When I used AI to implement that feature from the story #1. that was vibe-coding. The term didn’t exist back then, we just called it "AI-generated code." But let’s be honest, "vibe coding" sounds better.

Think of it like this: being a vibe-coder without foundational knowledge is like trying to be an electrician without proper training. At some point, you’ll get shocked... or start a fire.

That doesn’t mean you need a license or formal degree to be a developer. You can absolutely start with vibe coding. But to build stable, safe, and scalable software, you need more than prompts. You need to learn the basics: clean code, version control, security, system design. That’s what turns quick wins into long-term success.

If you ignore don't have basic programming skills, you risk introducing issues like:

• Security vulnerabilities that could expose user data and lead to legal trouble

• Bugs that frustrate users and drive customers away

• Performance issues that inflate cloud costs or degrade the user experience

When Vibe Coding Does Work

Proof of Concepts

Vibe coding is great for prototyping. Need to integrate a new library to see if it’s worth paying for? AI can spin up a working demo in minutes. Just point it at the docs and let it work while you drink coffee. For internal demos, it doesn’t need to be secure or pretty—just functional.

When Failure Is an Option

I’m not a frontend dev. That used to stop me from launching products. Now, with AI, I’ve built and sold a SaaS with frontend code that works but it would make a real frontend dev cry. And that’s fine. For a small project, where UI bugs aren’t dealbreakers, vibe coding works. But this would never fly in a mature product with real users and expectations.

Vibe coding is fine when you can afford to fail. But you'll never see NASA vibe-coding the navigation system for a spacecraft that puts astronauts on the ISS.

What Is AI-Assisted Coding?

AI-assisted coding is different. You don’t trust the AI blindly. You use it like a junior dev or a very fast pair programmer, you guide it, verify its output, and think critically at every step. Sure, it might take longer than vibe coding, but the goal is to produce results that match or even exceed your own expertise.

And it’s not just about writing code. AI can assist with all the unglamorous but essential parts of the job:

• Writing and updating documentation

• Generating tests

• Reviewing pull requests

• Drafting technical emails and status updates

• Exploring unfamiliar APIs or libraries

You can also use it to simulate pair programming: bouncing ideas off the model, thinking through architectural decisions, and even catching edge cases during reviews.

Used thoughtfully, AI becomes a productivity multiplier, not just a code generator.

That’s what this newsletter is all about: giving you real-world ways to use AI that make you a better, faster, and more reliable developer.... without putting your job or product at risk.

This first edition was about setting the stage and explaining my take on vibe coding vs. AI-assisted development. In the next issue, I’ll share actionable tips I’ve tested myself, stuff you can use right away to boost your workflow.

But what about you? What’s been your biggest aha moment with AI? Or your most frustrating failure? I’d love to hear your stories!

Thanks for reading and stay tuned!

public async Task ProcessIntentAsync(ITurnContext turnContext, CancellationToken cancellationToken)
{
    var query = turnContext.Activity.Text; // "What's the busiest queue today?"
    var userId = turnContext.Activity.From.Id;
    var tenantId = await _tenantResolver.GetTenantIdForUser(userId);

    // Get intent from Azure CLU
    var cluResponse = await _conversationsClient.AnalyzeConversationAsync(query);

    // Check if user has permission for this intent
    if (!await _permissionChecker.HasPermissionForIntent(userId, tenantId, cluResponse.TopIntent))
    {
        await turnContext.SendActivityAsync($"You don't have permission to access {prediction.TopIntent}.");
        return;
    }

    // Process the intent using a factory pattern
    var intentProcessor = _intentFactory.GetProcessor(cluResponse.TopIntent);
    if (intentProcessor != null)
    {
        await intentProcessor.ProcessAsync(turnContext, cluResponse.Entities);
    }
    else
    {
        await turnContext.SendActivityAsync("I'm not sure how to help with that.");
    }
}

Azure CLU Limitations: Why We Needed More

While this implementation worked, we quickly encountered several limitations:

Rigid Parameter Extraction

We had to define explicit entities for each parameter and handle missing entities manually:

private async Task HandleAgentPerformanceIntent(ITurnContext turnContext, List<Entity> entities)
{
    // Required entity extraction
    var agentEntity = entities.FirstOrDefault(e => e.Category == "AgentName");
    if (agentEntity == null)
    {
        await turnContext.SendActivityAsync("Please specify an agent name.");
        return;
    }

    var dateRangeEntity = entities.FirstOrDefault(e => e.Category == "DateRange");
    if (dateRangeEntity == null)
    {
        await turnContext.SendActivityAsync("Please specify a time period.");
        return;
    }

    // Continue with handler...
}

Maintenance Burden

Each new capability required extensive changes across multiple systems:

1. Creating and training a new CLU intent with dozens of examples

2. Adding entity definitions for any parameters

3. Adding a new case to our switch statement

4. Implementing a new handler method with parameter extraction

5. Adding permission checks specific to that intent

Contextual Amnesia

The bot couldn't maintain conversation context or understand follow-up questions:

First query: "What was my busiest queue last month?"
    Bot processes GetBusiestQueue intent successfully

Follow-up query: "And what about December?"
    CLU has no context from previous query, so this likely fails or matches a different intent entirely

Semantic Kernel Approach: Dynamic Function Selection

With Semantic Kernel, we eliminated hard-coded intent matching in favor of AI-powered function selection:

public class QueueAnalyticsPlugin
{
    [KernelFunction, Description("Gets statistics for the busiest queue within a specified time period.")]
    [Parameter("dateRange", "The date range to analyze (e.g., 'last month', 'yesterday', etc.)")]
    public async Task<string> GetBusiestQueue(string dateRange, KernelArguments arguments)
    {
        // Security and implementation...
    }

    [KernelFunction, Description("Compares call volumes between two queues over a time period.")]
    [Parameter("queue1", "The first queue to compare")]
    [Parameter("queue2", "The second queue to compare")]
    [Parameter("dateRange", "The date range to analyze")]
    public async Task<string> CompareQueues(string queue1, string queue2, string dateRange, KernelArguments arguments)
    {
        // Security and implementation...
    }
}

This approach allows the LLM to understand the user's intent and select the most appropriate function, even with varied phrasing and follow-up questions, while maintaining the same security guarantees.

The Semantic Kernel Plugin Architecture

Semantic Kernel allowed us to create a more powerful bot by organizing functionality into plugins that the LLM can intelligently select based on user intent.

public class SemanticKernelBot
{
    private readonly Kernel _kernel;
    private readonly IPermissionService _permissionService;

    public SemanticKernelBot(Kernel kernel, IPermissionService permissionService)
    {
        _kernel = kernel;
        _permissionService = permissionService;

        // Register all plugins
        RegisterPlugins();
    }

    private void RegisterPlugins()
    {
        // Register our domain-specific plugins
        _kernel.Plugins.AddFromObject(new QueueAnalyticsPlugin(_permissionService), "QueueAnalytics");
        _kernel.Plugins.AddFromObject(new AgentPerformancePlugin(_permissionService), "AgentPerformance");
        _kernel.Plugins.AddFromObject(new CallStatisticsPlugin(_permissionService), "CallStatistics");
    }
}

Plugin Implementation with Security Checks

Each plugin function automatically enforces security checks before accessing any data:

public class QueueAnalyticsPlugin
{
    private readonly IMediator _mediator;
    private readonly IPermissionService _permissionService;

    public QueueAnalyticsPlugin(IMediator mediator, IPermissionService permissionService)
    {
        _mediator = mediator;
        _permissionService = permissionService;
    }

    [KernelFunction, Description("Gets statistics for the busiest queue within a specified time period.")]
    [Parameter("dateRange", "The date range to analyze (e.g., 'last month', 'yesterday', etc.)")]
    public async Task<string> GetBusiestQueue(string dateRange, KernelArguments arguments)
    {
        // Extract tenant ID and user ID from context
        var tenantId = arguments["tenantId"] as string;
        var userId = arguments["userId"] as string;

        // Check permissions - this is the security boundary
        if (!await _permissionService.HasPermission(userId, tenantId, Permission.ViewQueueAnalytics))
        {
            return "You don't have permission to view queue analytics. Please contact your administrator.";
        }

        // Convert natural language date range to DateTime values
        var (startDate, endDate) = ParseDateRange(dateRange);

        // Reuse existing mediator query
        var result = await _mediator.Send(new GetBusiestQueueQuery(tenantId, startDate, endDate));

        return $"The busiest queue between {startDate:d} and {endDate:d} was {result.QueueName} with {result.CallCount} calls.";
    }
}

Reusing Existing Business Logic

A key advantage is that each plugin simply calls our existing mediator-based business logic:

// Inside our plugin
var result = await _mediator.Send(new GetBusiestQueueQuery(tenantId, startDate, endDate));

This means:

1. No duplication of business logic

2. Existing security checks remain in place

3. All tenant isolation guarantees are maintained

Natural Language Understanding with Context

Semantic Kernel enables the bot to maintain context across the conversation:

public async Task HandleMessageAsync(ITurnContext turnContext)
{
    var userQuery = turnContext.Activity.Text;
    var userId = turnContext.Activity.From.Id;

    // Get chat history for context
    var chatHistory = await _chatHistoryRepository.GetForUser(userId);

    // Execute query through Semantic Kernel with context
    var kernelArguments = new KernelArguments
    {
        ["userId"] = userId,
        ["tenantId"] = await _tenantResolver.GetTenantIdForUser(userId),
        ["history"] = chatHistory.ToString()
    };

    var result = await _kernel.InvokePromptAsync(userQuery, kernelArguments);
    await turnContext.SendActivityAsync(result.ToString());
}

This allows natural follow-up questions:

User: "What was my busiest queue last month?"
Bot: "The busiest queue in January was Support with 1,245 calls."
User: "What about December?"
Bot: "In December, the busiest queue was Sales with 982 calls."

The Best of Both Worlds: Hybrid Approach

While Semantic Kernel excels at conversation, CLU is still better for specific structured outputs like Adaptive Cards:

public async Task HandleMessageAsync(ITurnContext turnContext)
{
    var userQuery = turnContext.Activity.Text;

    // First check if this is a request for an Adaptive Card
    var cluResult = await _languageClient.PredictAsync(userQuery);

    if (cluResult.TopIntent == "MostBusyAgent" && cluResult.TopScore > 0.7)
    {
        // Use deterministic card generator
        var card = await _cardGenerator.CreateMostBusyAgentAdaptiveCard(cluResult.Entities);
        await turnContext.SendActivityAsync(MessageFactory.Attachment(card));
        return;
    }

    // Otherwise, use Semantic Kernel for natural language handling
    await HandleWithSemanticKernel(turnContext);
}

Multi-tenancy and Security: Never Compromised

Every function implements permission checks before accessing any data:

[KernelFunction]
public async Task<string> GetAgentPerformance(string agentName, string dateRange, KernelArguments arguments)
{
    var tenantId = arguments["tenantId"] as string;
    var userId = arguments["userId"] as string;

    // Security check #1: User permission
    if (!await _permissionService.HasPermission(userId, tenantId, Permission.ViewAgentData))
    {
        return "You don't have permission to view agent performance data.";
    }

    // Security check #2: Data boundary - ensure agent belongs to tenant
    if (!await _agentRepository.BelongsToTenant(agentName, tenantId))
    {
        return $"No agent named '{agentName}' was found in your organization.";
    }

    // Proceed with data retrieval...
}

These checks ensure:

• Users can only access data they're authorized to view

• No cross-tenant data leakage can occur

• All requests are properly scoped to the user's tenant

Conclusion

Transitioning to Semantic Kernel transformed the Clobba Teams Bot into a more powerful, context-aware assistant while maintaining strict security guarantees.

The key advantages:

1. Powerful natural language understanding that handles variations in phrasing

2. Contextual awareness that maintains conversation state

3. Security-first approach with permission checks in every function

4. Tenant isolation guarantees to prevent data leakage

5. Simplified development through plugin architecture

By combining the strengths of Semantic Kernel and Azure CLU, we've created a bot that's both more powerful and more secure—giving users a modern AI experience without compromising on security.

Below, I’ll outline our high-level approach for turning Clobba’s Teams bot into a secure, AI-driven experience. In the next post, I’ll share code samples that detail how Azure Conversational Language Understanding (CLU) and Semantic Kernel come together under the hood.

Background: Clobba Flex’s Multi-Tenant, Role-Based Setup

Clobba Flex provides dashboards, call analytics, and license usage reports, among other features, for multiple customers on the same infrastructure. Each user may have different permissions, and no one should ever see data belonging to another tenant. Needless to say, they take security seriously and have even obtained an ISO 27001 certification, highlighting their commitment to data security. This means that while adding an AI chatbot was a logical improvement for analyzing data with natural language, we couldn't just plug in a large language model (LLM) without addressing these challenges:

1. Cross-Tenant Data Isolation: One user’s query must never show another tenant’s information.

2. Secure Handling of Customer Data: In a world where companies still block access to AI due to fears of data leaks and misuse for training AI models (which is understandable), we must assure our customers that their data will not leave our infrastructure.

3. Accurate Reporting: LLMs are not known for their precision; they can sometimes make things up, which can cause confusion or lead to incorrect decisions for our customers.

First Attempt: Direct LLM Access

A simple approach would have been to connect an LLM directly to Clobba’s database or a smaller set of data and let it extract information from there. However, this option doesn't address any of the three important points mentioned above, so it's not a viable solution.

Moving to Azure CLU

Our initial solution was Azure Conversational Language Understanding (Azure CLU) because it provided us with the security and precision we needed. Here’s how it worked:

1. Define Intents: For each query type—like “Most Busy Queue”—we trained an intent with around 30 example utterances. Examples of utterances for this case would be “What queue had the most calls this month” or “Identify the queue with the most calls today”. Azure CLU allows us to extract entities, for example, we can instruct it to detect queue names or date ranges.

2. Check Permissions: If CLU recognizes an intent, the system verifies the user’s role. Valid users get their data; everyone else is refused with a nice message indicating the permissions they’re missing.

3. Add Q&A: We supplemented with Azure Question Answering so users can ask about Clobba’s features and functionality.

You can get a better idea of this flow by looking at the picture below.

When a user asks a question, we send it to Azure CLU, which returns the identified intent along with a confidence score. We have a mapping between the intents and the required permissions needed to process that intent. If the user lacks the necessary permissions, we send a friendly message informing them to request those specific permissions and try again.

Pros of using Azure CLU

• It’s fast! Each time you add or change intents you have to retrain the model and it takes a few minutes, but that’s not done very often. However, when sending a query to Azure CLU the intent is detected in 0.2-0.5 seconds.

• It makes ensuring data security easy. This method keeps data secure by using Clobba’s existing role checks. Although it uses AI to train the model with those utterances, it doesn’t access customer data. Only the utterances and user questions are sent to Azure CLU, while the information from the database goes directly to the user, not to Azure CLU. This approach reassured customers about their data privacy concerns when using AI.

• The cost is predictable. With Azure CLU, a Search Service is required, and while the Free Tier is available, it does not support Advanced Model Training for intents. This increases the risk of similar intents being confused, reducing accuracy.

  To ensure higher precision, we use the Basic Tier of Azure AI Search with one instance, costing around $75/month. This enables Advanced Model Training in Azure CLU, allowing us to refine intent recognition and improve accuracy.

Cons of using Azure CLU

It was predictable but limited—adding new features meant retraining more intents, which was time-consuming.

This meant that the bot was pretty limited because the conversation looked like this:

As you can see, the user asks a question and the Clobba Teams bot responds straight to the point. The problem is that it's not 2015 anymore; we're in 2025. Nowadays, when people talk with a bot, they expect a ChatGPT-level conversation where they can ask for more details or have the bot explain it in a way that they can understand. How can we achieve this while providing accurate responses without risking a security breach?

Integrating Semantic Kernel and Azure OpenAI

To expand the bot’s intelligence, we introduced Semantic Kernel with Azure OpenAI:

1. Plugin-Based Structure

   • Each plugin handles a specific task (e.g., “Retrieve Most Busy Queue”, “Retrieve most busy agent”, “Retrieve all queues”, etc. ).

   • The LLM parses user queries and calls the correct plugin.

   • Inside that plugin, we check if the user is allowed to access that data using the same security model.

2. Enterprise Data Protection

   • Azure OpenAI ensures that Code Software's customer data is not used for model training, aligning with ISO 27001 standards for secure data handling. The inputs, outputs, embeddings, and training data are not shared with other customers or OpenAI, nor are they used to improve models without our consent. The Azure OpenAI Service operates within Microsoft's Azure environment, ensuring data security and compliance with Azure's offerings.

3. Flexibility for Customers - we allow them to select how powerful the bot is

   • No Bot: Some clients opt out entirely.

   • Azure CLU Only: Deterministic approach with minimal overhead.

   • Azure CLU + Azure OpenAI: A more conversational experience under tight security constraints.

Here’s what a conversation looks like now:

As you can see, the conversation is more natural. What’s more, the user can now ask some difficult questions that Azure CLU could not interpret. An LLM is perfect at this because it can detect the context of the question and add the missing pieces without forcing the user to do that.

For example, an Azure CLU intent that requires a date range will not work unless the user specifies it.

E.g. “Show me the busiest queue for this month”

However, an LLM has the history of the conversation and knows that earlier I talked about a specific date range. Thus, the query will use that information - “January 2024”, “January 2025”.

Pros of using Semantic Kernel

• Strict Security: Plugins enforce permission checks before any data retrieval, ensuring a user never sees another tenant’s info.

• Maintained Precision: Rather than letting the LLM guess how to build SQL queries, each plugin executes vetted code paths.

• Easy Feature Expansion: No massive retraining each time—just add a new plugin.

• Natural conversation: It makes the conversation feel more natural, allowing users to speak as if they are talking to another person who understands the context.

Cons of using Semantic Kernel

• It's slower than Azure CLU. Behind the scenes, Semantic Kernel first sends the response to Azure OpenAI for processing. The AI decides that plugin A must be used, and then the result from the plugin goes back to OpenAI, which returns the final response.This process can take between 1 to 5 seconds, depending on the complexity of the query, which is longer than Azure CLU. However, in my opinion, the results are worth the wait.

• For debugging, it’s inherently unpredictable. Unlike compiled code, where you can reliably reproduce bugs and patch them, the non-deterministic nature of LLMs means there’s no guarantee you’ll even see the same issue twice. If an incorrect plugin call occurs, it might not happen the same way again, so you often have to accept it rather than fix it in the usual way.

• Unpredictable costs. With Azure CLU, we generally know the monthly cost, but Azure OpenAI uses a pay-per-use model. Costs depend on the number of tokens processed for both inputs and outputs. This means pricing increases with usage, which can make it more expensive than CLU, but also more flexible. In a future article, I'll share strategies to save costs for both Azure OpenAI and CLU, including tips to optimize search usage and cut unnecessary spending.

Next Steps

In the upcoming article, I’ll share code samples that show how we connected Azure CLU, Semantic Kernel, and Azure OpenAI behind the scenes. You’ll learn how we enforce permissions and tackle the challenge of creating prompts that ensure precision.

Recently, I encountered a costly issue with my application. A misconfigured Polly retry policy caused over 80 million retries to a 3rd-party API within just two days. Each retry failure generated logs in the AppEvents and AppExceptions tables of my Azure Log Analytics workspace linked to Application Insights. This caused a big increase in data ingestion, leading to an unexpected rise in my Azure costs. Normally, I pay about 70 EUR per month, but this month I had to pay 150 EUR, effectively doubling my costs.

The main problem was that the Polly retry logic failed to handle the rate limit headers correctly because the API, for some reason, sent a RetryAfter value of 0 instead of providing an appropriate wait time. This led to requests being retried too frequently, despite the API's advice to pause, which in turn flooded the logging system with telemetry data.

Steps Taken to Prevent This in the Future

To address this issue and avoid a similar situation in the future, I implemented several measures, including daily ingestion caps, telemetry sampling, alerts, and data purging. Here’s how you can configure these features in Application Insights to ensure cost-effective monitoring and logging.

1. Configure Daily Caps in Log Analytics

Daily caps are an effective way to prevent runaway data ingestion costs. If your application unexpectedly generates excessive telemetry, the daily cap will stop data ingestion once the cap is reached, protecting you from unexpected billing spikes.

How to Set a Daily Cap:

1. Go to your Log Analytics Workspace in the Azure portal.

2. Navigate to Usage and estimated costs in the left menu.

3. Select the Daily cap tab.

4. Set the desired cap in GB (e.g., 2 GB/day).

5. Save the settings.

Azure will stop data ingestion for the day once the cap is reached. Note that ingestion resumes the next day.

2. Implement Telemetry Sampling in Application Insights

Telemetry sampling reduces the volume of data sent to Application Insights by collecting a representative subset of telemetry data. This ensures you retain insights into application behavior while keeping ingestion volumes under control.

How to Enable Telemetry Sampling:

1. Open your Application Insights resource in the Azure portal.

2. Navigate to Sampling under the Configure section.

3. Enable Adaptive Sampling:

   • Adaptive Sampling dynamically adjusts the sampling rate based on the volume of incoming telemetry.

4. Adjust sampling rates for specific telemetry types (e.g., reduce detailed logs while keeping critical exceptions).

This ensures that only essential logs are sent to the workspace, reducing data ingestion without losing valuable insights.

3. Configure Alerts to Monitor Unexpected Behavior

Alerts help you detect spikes in telemetry data before they escalate into high costs. By monitoring key metrics, such as data ingestion rates or exception counts, you can act quickly to resolve the underlying issue.

How to Set Up Alerts:

1. In your Application Insights resource, go to Alerts in the left menu.

2. Click + New alert rule.

3. Configure the alert:

   • Scope: Select your Application Insights resource.

   • Condition: Choose a signal like Exceptions > Count or Data Ingestion > Volume.

   • Threshold: Set a threshold (e.g., trigger when exceptions exceed 1000 in 5 minutes).

   • Action Group: Define an email or SMS notification for the alert.

4. Save and enable the alert.

This allows you to receive notifications when unusual patterns emerge, such as a sudden increase in exceptions or retries.

4. Purge Unnecessary Data with the REST API

After identifying the source of the excessive logs, I needed to remove the unnecessary data to clean up my workspace, hoping it would lower my bill. However, that's not the case. You are billed for the data you logged at the end of the day, so purging the data after two days didn't affect my invoice. Still, you might want to do this, so here's how I did it step-by-step:

Step 1: Assign the Data Purger Role

1. Go to your Log Analytics Workspace in the Azure portal.

2. Navigate to Access Control (IAM).

3. Add a role assignment:

   • Role: Data Purger

   • Assign access to: Your Application Insights or service principal.

Step 2: Generate an Access Token

1. Use Azure CLI or Postman to generate a token:

    az account get-access-token --resource https://management.azure.com/
   

   Use the token in the Authorization header of your requests.

Step 3: Send a Purge Request

1. Use the following POST endpoint:

    POST https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.OperationalInsights/workspaces/{workspaceName}/purge?api-version=2023-09-01
   

2. Include the following request body (set the value to whatever you need to purge):

    {
      "table": "AppExceptions",
      "filters": [
        {
          "column": "Type",
          "operator": "=",
          "value": "Polly.RateLimit.RateLimitRejectedException"
        }
      ]
    }
   

3. Monitor the operation with the returned operationId. In my case it took more than 24 hours for the purge to execute.

Conclusion: Why Configuring Application Insights is Essential

This experience highlighted the importance of properly configuring Application Insights to prevent high costs and ensure effective telemetry management. By implementing daily caps, telemetry sampling, alerts, and data purging, you can:

• Prevent runaway data ingestion costs.

• Reduce unnecessary logs while retaining critical insights.

• Detect and respond to unusual application behavior early.

• Maintain a clean and manageable telemetry dataset.

By taking these steps proactively, you can safeguard your monitoring budget and ensure your application remains performant and cost-effective.

A month ago, my biggest challenges were things like making sure a page was responsive or optimizing a database query. But now? Navigating the Romanian tax system for international SaaS sales feels like a whole new level of complexity. It’s almost enough to make me consider shutting down this little experiment because of the headaches involved.

Let me break down the numbers to give you a clear picture:

Since enabling Stripe on October 17th, I’ve sold 10 licenses for a total of €66. Stripe’s commission takes €4 (I think there’s also a VAT charge here), so I’m left with €62.

Then, my accountant charges €30 + VAT for processing up to 100 invoices each month (this doesn’t include the €84/month I already pay them for managing my PFA—let’s leave that out for now).

So after the accountant’s fees, I’m left with ~€26. Of course, I can have 90 more customers included in this price, but the idea is that you can't have a SaaS that barely makes any money, otherwise just accounting will kill it.

There’s also the tax that I need to pay in Romania, so I’ll be left with less than €20-€25 after this.

What about hosting? Well, Azure will cost me ~70EUR/month for the current usage, probably I can fit 100-200 more clients before I need to scale up, so I'm already losing money.

But it doesn’t end there...

Stripe collects VAT for each sale but leaves the actual VAT remittance to me. Within the EU, I can handle this through Romania’s OSS system, which simplifies things. But for non-EU countries like the UK, I’d need to register and remit VAT separately in each country where I have sales. I have no idea how much this would cost and I don’t intent to find out, so I refunded the customer for now and let them keep their license.

And there’s more: for Romanian customers, I also need to issue an e-factura (electronic invoice), which Stripe doesn’t support—so that’s on me too.

Given all this complexity, the simplest option might be to shut it down and refund the payments. But I’m not ready to give up yet! Instead, I’m looking into Paddle as an alternative.

Why Paddle?

Paddle acts as a Merchant of Record (MoR), essentially a reseller for my product. They handle all the VAT collection and remittance in each country, and they take care of compliance with local tax authorities. This means I’ll receive just one monthly invoice from Paddle, instead of needing to manage VAT and invoices for each individual sale. In theory, this should make everything much simpler—and hopefully let me get back to focusing on building features, not dealing with tax filings!

It’s a bit disappointing that I need to switch payment processors instead of working on new product features, but it’s a necessary step.

I'll keep you posted on the process once I’m done with the Paddle integration (still waiting for their approval).

📣 To my fellow Romanian SaaS creators—if you've faced these challenges and have any tips to share, I’d love to hear from you!

Being a backend developer, I always felt more comfortable with the server-side stuff, but taking an idea and turning it into a product people could actually use—frontend and all—that’s where things got tricky. So, I finally decided to challenge myself: pick a simple idea, build it, and actually launch it. No overthinking, no polishing things until they’re perfect. Just build and ship.

This article is about how I made that happen, focusing on shipping something usable instead of waiting for perfection.

What was stopping me from launching a SaaS?

If you're looking to launch a product and want to reach a large audience, my opinion is that building a web app is the best way to go. Better yet, a PWA can give your app a native feel, and you don’t have to worry about building apps for different platforms. But what happens when most of your experience is in backend development? Sure, any developer can put together a basic website, but it's 2024, not 1994—your app needs to do more than just work; it needs to stand out. That was the first hurdle I faced when I had an idea.

Another challenge I’ve always faced is discouraging myself early on. If I worked for a week or two and saw another similar app, I would convince myself there was no point in continuing—after all, why build something that's already out there? Or, worse, if I heard someone dislike a similar app, I would assume everyone would hate mine too. Over the years, this led to several ideas being abandoned, many of which others eventually built.

But last month, I decided to break that cycle. I challenged myself to build a simple app and launch it.

The Idea

The goal of this challenge was simple: to launch the product. Success wasn’t tied to any financial targets or milestones—it was purely about shipping something quickly. That’s why I decided to build on something I’d already created a few years ago, a small Blazor app I used personally to analyze my Todoist tasks and plan long-term. Todoist is a simple app great for planning your tasks for today or this week, but it’s not that good for thinking way ahead into the future, planning more complex tasks (goals) or even showing you some statistics about your productivity. I figured that if it’s helpful for me and I already have some of the functionality done, then it should be useful for others as well and it wouldn’t take long to rewrite it into a SaaS product. I was wrong on the last part, what I thought would take 1 week actually took almost 2 weeks, but funny enough it’s not the development part that required the most work.

For example, I spent a lot of time obsessing over a name and domain, until I realized I was wasting more time on this than on the actual implementation. In the end, I went with https://task-analytics.com

Writing frontend code with AI

Now let’s get back to my challenge, the key was to develop something simple and usable. I didn’t want to spend months developing the app, knowing that the longer I worked on it, the greater the risk of losing momentum and quitting. However, there’s still the frontend issue!

As a .NET developer, it’s easier for me to pick up Blazor than to dive into React or Vue. Still, Blazor doesn’t make the frontend magically easy—knowledge of HTML/CSS is still required, and most of my frontend experience consists of admin interfaces (simple to use, not responsive), or using predefined components that are simple to use but they are not “beautiful” by default (Radzen, Syncfusion, etc). So, should I start learning frontend development? Honestly, life is too short for that, especially when AI tools can step in. At the end of August I heard that Cursor AI is generating some good impressions so I thought it’s time to try it as well. This is a tool that integrates AI right into your code editor. If you’re familiar with VS Code, Cursor AI feels like home since it's a fork of VS Code, but with AI built into it.

Here’s an example: I can create an empty Settings.razor page, then give it a prompt like the one below:

Implement the settings page UI and functionality. Make sure it’s consistent with the Home page. The settings page should include a profile picture, user name, join date, and a sign-out button. Call the user info endpoint when the page initializes, and prompt the user on sign-out to confirm. If they say yes, clear the cache and redirect to the home page.

In response, Cursor generates the code in less than 30 seconds. If it looks good, I hit a button and apply the changes. If not, I can keep chatting with the AI to tweak it.

An experienced developer could probably write the functionality in minutes, but it’s the UI that’s tricky. In my opinion, the hardest part of frontend work isn't writing the code—it’s the design. Without a clear design, I spend more time tweaking layouts and colors than actually writing new functionality. With AI, I can give broad directions like “make it consistent with the Home page,” and it ensures the pages have the same structure and color scheme. If I don’t like the look, I can prompt, “make it more modern” and the AI adjusts the design. Of course, that’s a pretty bad prompt and I use it only when I don’t know what I want, I just know I don’t like it 😅. Most likely it might not get great results, but the more descriptive I get, the better the output.

Another benefit is handling responsiveness. I can simply prompt, “make it responsive,” and then test it on different screen sizes. If something’s off, I can tell it what needs to be changed by writing the requirements or I can upload screenshots and have the AI fix the UI. Sometimes I’ll even use a combination of Chat GPT and Cursor AI, for example I give a screenshot of my page to Chat GPT and tell it to roast it and write requirements as a conclusion, then I just give those requirements to Cursor AI.

I’ll make a YouTube video this week where I’ll go through some example to see where AI handles the task very well, but also where it screws things up and you spend more time improving the prompts instead of writing the actual code.

Balancing Perfection and Practicality

Now, Cursor AI isn’t perfect—it’s far from it. It still makes mistakes, and sometimes it takes longer to generate code than writing it manually as I said above. But with practice, you learn which prompts work best and which to avoid. For me, it made frontend development feasible, even though I hadn’t touched CSS in over a decade. I’m not a frontend developer but even I can tell that the Lighthouse score in the screenshot below is pretty bad, and it proves that AI doesn’t produce flawless code.

If the app proves successful, I'll definitely invest time into optimizing it or even bringing in a designer. But, as I mentioned before, the goal was to launch something usable, not perfect. Sometimes, that approach clashed with my usual instincts, especially on the backend. I love squeezing every bit of performance out of my code, but this wasn’t the time for that. For instance, I started writing Azure Functions for handling heavy operations, only to realize I was about to spend 1-2 days on something unnecessary at this stage. Instead, I opted for a simpler solution that I could write in 30 minutes. It was tough to take this route, knowing all too well the risks of technical debt. But in the end, I’m more satisfied with having launched something practical rather than perfect.

The point wasn’t to create an open-source project showcasing flawless .NET code—it was about sticking to the core goals and priorities. That said, my app isn’t slow or expensive to run, I pay around 50-60 EUR/month for Azure and I would probably need to scale up when I go over 100-200 users, or make some serious performance improvements. Until then, I can focus working on new functionalities.

Just to be clear, I’m not advocating for cutting corners to the point where it harms the product. I’ve seen indie developers justify junk code in paid apps that barely function, and I have no intention of going down that road..

Writing backend code with AI

I also used Cursor AI on the backend when things got repetitive or too simple to bother coding manually.

Even though I made some exceptions on the performance and quality, there were still some things that I wasn’t willing to give up on. For example, implementing a good CI/CD pipeline, not having any warnings, writing some unit tests for critical areas of the business logic and writing clean code overall. Even though I have a decent amount of backend code generated by AI, I made sure it respects basic principles of clean code. Sometimes I actually had AI refactor my code by giving it some similar classes and asking it to remove the code duplication, which it handled pretty well. If you want more tips on using AI in your code, I have a LinkedIn post about this you can read.

Conclusion

If I were to develop this app in an enterprise setting, it would easily take a year. First, you’d spend 2-3 months planning the app, followed by another few months just getting approvals. Then comes the implementation phase, where a significant amount of time would be spent reviewing code and debating things like whether to use microservices or a monolithic architecture 😅.

Now that my app is live (and it even has paying users), I can consider this challenge complete. But this is just the beginning. As the title says, this is my first SaaS app, I’m not stopping here. I have more ideas in the pipeline, and I plan to build in public to show how you can build your own product as a .NET developer, even if your expertise lies mostly in the backend. I’ll follow up with more blog posts and YouTube videos that will have more details about my journey, so make sure you follow me if you want to know more!

1. Port 80 is no longer the default

This project is an ASP.NET Web API on .NET 7 and it's really fresh, a few days old, but I still had issues upgrading to .NET 8. When I deployed the project to Azure Container Apps I got this error:

upstream connect error or disconnect/reset before headers. retried and the latest reset reason: remote connection failure, transport failure reason: delayed connect error: 111

After ~30 minutes I figured out that .NET 8 is listening on port 8080 instead of 80, and when I googled this I immediately found out that this is a breaking change. Here's the link with more details:

https://learn.microsoft.com/en-us/dotnet/core/compatibility/containers/8.0/aspnet-port

I'll update this blog post when I have more stuff.

Before we get started I'd like to point out that I'll only show certain parts of the Bicep files just to keep this article as short as possible, but you can find the repository link at the end of the article.

How The Bicep Files Will Work

1. Variables: We will get the DB_ADMIN_USERNAME and DB_ADMIN_PASSWORD from our Azure DevOps pipeline variables.

2. PowerShell Script: These variables will then be fed into our PowerShell script, which will trigger the Bicep deployment.

3. SQL Server Module: A separate Bicep module will handle the creation of the SQL Server, generating a connection string as an output.

4. App Service Module: This connection string will then be used as a parameter in another Bicep module that creates the App Service.

5. Configuration: The connection string will be added to the App Service configuration under the connection strings instance.

6. SKU and Tier: We also have a JSON configuration file that specifies the SKU and tier of the database, which for this example will be Basic.

Bicep Code Explained

The main.bicep file combines the modules for the SQL Server and the App. The SQL Server module gets its parameters like databaseSku, databaseTier, databaseAdminUserName, and databaseAdminPassword from the main Bicep parameters.

Here is a snippet from main.bicep:

module sqlServer 'sqlserver.bicep' = {
  name: 'sqlserver'
  params: {
    prefix: prefix
    location: location
    sku: databaseSku
    tier: databaseTier
    administratorLogin: databaseAdminUserName
    administratorLoginPassword: databaseAdminPassword
  }
}

The sqlserver.bicep module is responsible for creating the SQL Server. It also generates a connection string which will be outputted and used by the app.bicep module.

output dbConnectionString string = connectionString

The app.bicep module creates the App Service and attaches the SQL database to it via the connection string.

param connectionString string
resource webApp 'Microsoft.Web/sites@2022-03-01' = {
  // ... (other properties)
  properties: {    
    // ...
    siteConfig: {
      connectionStrings: [
        {
          connectionString: connectionString
          name: 'DefaultConnection'
          type: 'SQLAzure'
        }
      ]
    }
  }
}

The prod.json/qa.json configuration files will specify database details such as its SKU and tier. We can use different values according to our environment. In this case, I'll use Basic for both, but in real-world applications, you might use a lower tier for non-prod environments and a more powerful one for the production environment.

{
  "parameters": {
    // ...
    "databaseTier": {
      "value": "Basic"
    },
    "databaseSku": {
      "value": "Basic"
    }
  }
}

The full source code is available on this Azure DevOps repository:
https://dev.azure.com/bujdea/_git/AzureDevopsYamlPipeline

Conclusion

In a real-world application you would also configure database backups using Bicep, allow managed identity authentication, and so on... but for this tutorial, I wanted to keep things simple and show you how easy it is to spin up an Azure SQL Server instance using Bicep. If you would like me to expand on this topic just drop a comment below 👇

As you can see in the screenshot above, it takes ~1m 15s to run a deployment that doesn't have any infrastructure changes.

As a solution, you might consider disabling the Bicep deployment altogether, triggering it manually only when required. But that approach has its pitfalls: What if you deploy a new feature requiring infrastructure modifications but forget that critical manual step? You risk breaking your application, causing downtime for your users until you update the infrastructure and redeploy.

To sidestep these issues, we'll employ a more surgical method: using Git commands to detect changes in our Bicep files, triggering the infrastructure deployment only when necessary. This not only streamlines the process but also minimizes the risk of human error.

Using Git to detect changes in Bicep files

Azure DevOps doesn't offer a straightforward mechanism to conditionally run a pipeline step based on changes to specific files or folders. To work around this limitation, we'll leverage Git, specifically the git diff command, to achieve this granular control.

Before we can execute any git commands we have to fetch our repository, so I'll use this command:

- checkout: self
    fetchDepth: 0

Now we are going to add a script step in our pipeline which will check if there are any .bicep files modified and put this result into a variable. Our script looks like this:

- script: |
     echo "##vso[task.setvariable variable=RunBicepDeployment]$(git diff --quiet HEAD HEAD~1 **/*.bicep; echo $?)"

I know it looks very messy, so let's break it down in two parts:

1. Checking if Bicep files have been modified in the latest commit

1. Setting a variable in our pipeline with the result of the previous command

To check if any .bicep files have been modified we use this command:

git diff --quiet HEAD HEAD~1 **/*.bicep; echo $?

Here's a breakdown of each component of this command:

• git diff: The basic command to show differences between two points in your Git history.

• --quiet: This flag suppresses output and focuses solely on the exit status. The exit status tells you whether or not there are differences.

• HEAD: Represents the latest commit in the current branch.

• HEAD~1: Represents the commit just before the latest commit in the current branch.

• **/*.bicep: A glob pattern indicating that we're interested in any .bicep files, regardless of their location in the directory structure.

• echo $?: Outputs the exit status of the last command. If the exit status is 0, it means there's no difference; otherwise, it'll be 1, indicating a difference.

Putting it all together, this command compares the current and previous commits, checks if any .bicep files have changed, and then echoes the result. An exit code of 0 means no change, and 1 means there is a change.

The next step is to set a variable with this exit code so we can reuse it in another task:

echo "##vso[task.setvariable variable=RunBicepDeployment]$(git diff --quiet HEAD HEAD~1 **/*.bicep; echo $?)"

echo "##vso[task.setvariable variable=RunBicepDeployment]: This is Azure DevOps specific syntax to set a pipeline variable. It sets a variable named RunBicepDeployment which we'll reuse in the next step:

- task: AzureCLI@2
  displayName: 'Deploy Bicep Infrastructure'
  inputs:
    azureSubscription: 'AzureConnection'
    scriptType: 'pscore'
    scriptLocation: 'scriptPath'
    scriptPath: './infrastructure/deploy.ps1'                
    arguments: '$(resourceGroupName) $(location) $(configFileName)'
  condition: eq(variables.RunBicepDeployment, '1')

Our Deploy Bicep Infrastructure task has only one change, the condition added at the end which allows the task to run only if the RunBicepDeployment variable equals 1.

Our entire stage looks like this:

stages:
- stage: QA
  displayName: 'Deploy To QA Env'
  dependsOn: Test
  variables:
    location: 'westeurope'
    configFileName: 'qa.json'
    resourceGroupName: 'azure-devops-yaml-pipeline-qa'
    stagingAppUrl: 'https://bogdan-todo-qa-app-staging.azurewebsites.net/health'
  jobs:
    - job: UpdateAzureResources
      steps:
        - checkout: self
          fetchDepth: 0
        - script: |
            echo "##vso[task.setvariable variable=RunBicepDeployment]$(git diff --quiet HEAD HEAD~1 **/*.bicep; echo $?)"
          displayName: Check Bicep Changes
          name: setRunBicepDeployment
        - task: AzureCLI@2
          displayName: 'Deploy Bicep Infrastructure'
          inputs:
            azureSubscription: 'AzureConnection'
            scriptType: 'pscore'
            scriptLocation: 'scriptPath'
            scriptPath: './infrastructure/deploy.ps1'                
            arguments: '$(resourceGroupName) $(location) $(configFileName)'
          condition: eq(variables.RunBicepDeployment, '1')
    - job: Deploy
      dependsOn: UpdateAzureResources
      steps:
        - task: DownloadPipelineArtifact@2
          displayName: 'Download pipeline artifact'
          inputs:
            buildType: 'current'
            artifactName: 'drop'
            targetPath: '$(Pipeline.Workspace)/drop'
        - task: AzureWebApp@1
          displayName: 'Deploy to QA'
          inputs:
            azureSubscription: 'AzureConnection'
            appType: 'webAppLinux'
            appName: 'bogdan-todo-qa-app'
            package: '$(Pipeline.Workspace)/drop'
            resourceGroupName: $(resourceGroupName)
            runtimeStack: 'DOTNETCORE|7.0'
            startUpCommand: 'dotnet ToDoApp.Server.dll'

If we push this change we notice that the Bicep deployment is skipped:

Conclusion

By incorporating this Git-based conditional logic into our pipeline, we've made it substantially more efficient. Now, the Bicep deployment step takes less than a second when there are no changes to the .bicep files. While saving a minute may not seem significant, it's important to recognize that this is a simplified example featuring only an app service and an app service plan. In a more complex, real-world application, the Bicep files would likely be far more intricate, potentially taking several minutes for each unnecessary deployment. Over time, these saved minutes add up, accelerating the time-to-market for new features and bug fixes. Moreover, for pipelines that run frequently, these efficiencies can also translate into cost savings.

The code and the pipeline I'm using to showcase these articles can be accessed here:

https://dev.azure.com/bujdea/_git/AzureDevopsYamlPipeline

https://dev.azure.com/bujdea/AzureDevopsYamlPipeline/_build?definitionId=16

Feel free to subscribe to the newsletter below or follow me on Twitter if you'd like to be notified as soon as possible when I post my next article!

Our QA environment was a mirror image of our production environment and that's okay for now, but this isn't always the case in real-life applications.

As you can see, we have a staging slot in our QA resource group, but do we really need it?

To Slot or Not to Slot on QA:

The immediate consequence of omitting the staging slot for our QA environment is a minor downtime during deployments. However, considering it's the QA environment, a brief pause is acceptable. Why? Let's break it down:

1. Cost Efficiency: By doing away with the staging slot, we can downgrade from the S1 tier to the B1 tier for our app service plan specifically for the QA environment. This transition alone saves approximately 50 EUR/month.

2. Resource Optimization: By aligning resources more appropriately to their intended purpose (QA vs. Production), we ensure that we're not over-provisioning for a testing environment.

Now that we decided to remove it, you may be tempted to just go into Azure and delete the deployment slot, then manually downgrade the tier of the App Service Plan. However, if you do that, then on the next pipeline run the slot will be created again and our App Service Plan will get back up to the S1 tier.

At first glance, it might seem tedious to modify Bicep files for every infrastructure change. However, consider this: using Bicep ensures consistent, automated, and error-free updates. And, realistically, how frequently do you actually alter your infrastructure?

To optimize our QA environment, we'll adapt our Bicep configurations to exclude the staging slot and shift the app service plan from S1 to B1. This approach is practical, cost-efficient, and tailored to our specific deployment needs. Let's do this in 3 steps:

1. Introducing a parameter within our configuration files.

2. Incorporating this parameter into our Bicep definitions

3. Facilitating deployments contingent on the established parameter value.

Creating a parameter in configuration files

We introduce a hasStagingSlot parameter in our configuration files to determine whether a staging slot should be deployed.

For the Production environment, hasStagingSlot is set to true:

{
    "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentParameters.json#",
    "contentVersion": "1.0.0.0",
    "parameters": {
      "location": {
        "value": "westeurope"
      },
      "appName": {
        "value": "bogdan-todo"
      },
      "appSku": {
        "value": "S1"
      },
      "hasStagingSlot": {
        "value": true // on prod environment we want the slot to be deployed
      }
    }
  }

For the QA environment, hasStagingSlot is set to false:

{
    "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentParameters.json#",
    "contentVersion": "1.0.0.0",
    "parameters": {
      "location": {
        "value": "westeurope"
      },
      "appName": {
        "value": "bogdan-todo-qa"
      },
      "appSku": {
        "value": "B1"
      },
      "hasStagingSlot": {
        "value": false // on qa environment we don't want the slot to be deployed
      }
    }
  }

We also change the appSku value to B1.

Integrating with Bicep

The main.bicep file receives the hasStagingSlot variable and passes it onto app.bicep as a parameter.

...
param hasStagingSlot bool = false // we can add a default value if we want

module app 'app.bicep'  = {
  name: 'bogdan-todo-app'
  params:{
    location: location
    appName: appName
    appSku: appSku
    hasStagingSlot: hasStagingSlot // we send this parameter to our app.bicep module
  }
}

Conditional deployment based on the parameter value

In app.bicep, the deployment of the staging slot depends on the state of hasStagingSlot

app.bicep

...
param hasStagingSlot bool // this is our variable which decides if we're creating the slot or not
...

// using the if statement we will deploy the slot
// only if hasStagingSlot is true
resource webAppSlot 'Microsoft.Web/sites/slots@2022-03-01' = if (hasStagingSlot) {
  name: 'staging'
  location: location
  kind: 'app,linux'
  parent: webApp
  properties:{
    enabled: true
    httpsOnly: true
    siteConfig: {
      httpLoggingEnabled: true
      linuxFxVersion: 'DOTNETCORE|7.0'
    }
  }
}

This segment essentially states that the staging slot will only be deployed if hasStagingSlot is true.

There's one more thing we have to do, we need to remove the slot deployment from our qa.yaml stage:

...
- job: Deploy
  dependsOn: UpdateAzureResources
  steps:
    - task: DownloadPipelineArtifact@2
      displayName: 'Download pipeline artifact'
      inputs:
        buildType: 'current'
        artifactName: 'drop'
        targetPath: '$(Pipeline.Workspace)/drop'
    - task: AzureWebApp@1
      displayName: 'Deploy to QA'
      inputs:
        azureSubscription: 'AzureConnection'
        appType: 'webAppLinux'
        appName: 'bogdan-todo-qa-app'
        package: '$(Pipeline.Workspace)/drop'
        resourceGroupName: $(resourceGroupName)
        runtimeStack: 'DOTNETCORE|7.0'
        startUpCommand: 'dotnet ToDoApp.Server.dll'

Now let's deploy the changes and see what happens!

Our pipeline was deployed successfully, but when we look at our QA environment we still see the staging slot:

When a resource is missing from a Bicep file but exists in Azure, Bicep doesn't automatically delete it. Here's why:

1. Safety: Deleting resources can be destructive. Imagine accidentally removing a database with valuable data. By not auto-deleting, Bicep ensures safety.

2. State Management: Bicep and ARM templates are declarative. This means you declare your desired state, and Azure ensures that the actual state matches. However, they don't maintain a history of previous states. So, when a resource is omitted from the Bicep file, Bicep doesn't necessarily recognize it as a directive to delete; it just sees it as "not part of the current directive."

3. Explicitness: The philosophy behind tools like Bicep is that operations, especially destructive ones, should be explicit. Removing a resource from a Bicep file is implicit. If you want to delete a resource, it's generally better to do it explicitly, ensuring you're aware of the ramifications.

This basically means we have to go do it ourselves manually. Now that we updated our Bicep files, the staging slot will only be used in the production environment.

Takeaways

When to Use Conditional Deployment:

1. You need to maintain different configurations for dev/test vs. production.

2. There are cost constraints and you want to deploy certain resources only when absolutely necessary.

How to do conditional deployments:

1. Use configuration files with different values per environment

2. Use the if statement for conditional deployments based on your conditions

Conclusion:

Conditional deployments provide precise control over our infrastructure configuration. They optimize resource usage and can significantly minimize deployment errors. However, like all tools, they have their appropriate applications. Assess your needs, understand the circumstances, and employ them wisely.

The full source code can be downloaded from here: https://dev.azure.com/bujdea/_git/AzureDevopsYamlPipeline

What's next

In the next article, I will demonstrate how to add application settings using Bicep. Feel free to subscribe to the newsletter below or follow me on Twitter if you'd like to be notified as soon as possible!

Before diving in, I highly recommend reading these two articles first:

Bicep Infrastructure Deployment from Azure DevOps YAML Pipelines

and

Azure DevOps Best Practices: Breaking Down the Monolithic YAML

After reading those articles, you will comprehend how to deploy an app using Azure DevOps pipelines and Bicep, as well as grasp the reasoning behind dividing my infrastructure code into multiple files.

If you have already done so or already have this knowledge, feel free to proceed with the rest of the article!

Provisioning a New Environment Using Bicep

There are various ways to separate environments, but my usual preference is to have one resource group for each environment, which is what I'll demonstrate in this guide.

The beauty of this approach is its ability to logically isolate environments. By separating resources into distinct resource groups according to their environment, management and monitoring become significantly more effortless.

If you remember, the primary configuration for our environment was stored in a prod.json file. This file contains crucial details, like the tier of the App Service, its SKU, and environment-specific prefixes (e.g., "prod"). Here is the file that we already have in our project:

{
    "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentParameters.json#",
    "contentVersion": "1.0.0.0",
    "parameters": {
      "location": {
        "value": "westeurope"
      },
      "appName": {
        "value": "bogdan-todo"
      },
      "appSku": {
        "value": "S1"
      }
    }
}

If we want another environment we should first add another file in the configurations folder, so let's continue with the first step!

Step 1: Create a New Configuration File

Start by adding a new file named qa.json in your configurations directory. This file will define settings tailored to the QA environment, setting it apart from production or any other environments you might have.

{
    "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentParameters.json#",
    "contentVersion": "1.0.0.0",
    "parameters": {
      "location": {
        "value": "westeurope"
      },
      "appName": {
        "value": "bogdan-todo-qa"
      },
      "appSku": {
        "value": "S1"
      }
    }
  }

Step 2: Adjust Environment-Specific Variables

Inside qa.json, alter variables to reflect the QA environment's attributes. This could involve tweaking parameters like the App Service tier, resource names, or any environment-specific metadata. In my file, I made just one change, the appName parameter was set to bogdan-todo-qa

I did this because we can't have two identical subdomains under the same domain (azurewebsites.net). Since I already have bogdan-todo-app.azurewebsites.net I need to change the appName to something else, in our case, it will be bogdan-todo-qa-app.azurewebsites.net

Step 3: Create the pipeline stage for this environment

I think it's a good idea to break your pipeline into multiple components, so that's why I have each environment with its own stage. For the production stage we already have the file production.yaml, so let's create one for QA as well.

stages:
- stage: QA
  displayName: 'Deploy To QA Env'
  dependsOn: Test
  variables:
    location: 'westeurope'
    configFileName: 'qa.json'
    resourceGroupName: 'azure-devops-yaml-pipeline-qa'
  jobs:
    - job: UpdateAzureResources
      steps:
        - task: AzureCLI@2
          displayName: 'Deploy Bicep Infrastructure'
          inputs:
            azureSubscription: 'AzureConnection'
            scriptType: 'pscore'
            scriptLocation: 'scriptPath'
            scriptPath: './infrastructure/deploy.ps1'                
            arguments: '$(resourceGroupName) $(location) $(configFileName)'
    - job: Deploy
      dependsOn: UpdateAzureResources
      steps:
        - task: DownloadPipelineArtifact@2
          displayName: 'Download pipeline artifact'
          inputs:
            buildType: 'current'
            artifactName: 'drop'
            targetPath: '$(Pipeline.Workspace)/drop'
        - task: AzureWebApp@1
          displayName: 'Deploy to QA app service'
          inputs:
            azureSubscription: 'AzureConnection'
            appType: 'webAppLinux'
            appName: 'bogdan-todo-qa-app'
            package: '$(Pipeline.Workspace)/drop'
            resourceGroupName: $(resourceGroupName)
            runtimeStack: 'DOTNETCORE|7.0'
            startUpCommand: 'dotnet ToDoApp.Server.dll'

I copy-pasted my production.yaml to qa.yaml, but I still had to make some changes:

• the name of the stage was changed to QA , also the displayName was updated

• We need a new resource group for this environment, so I changed the name of the resourceGroupName variable to 'azure-devops-yaml-pipeline-qa'

We also have to update our production.yaml so that it will not depend on the Test stage anymore. We need to prevent our production deployment if the QA deployment fails.

stages:
- stage: Production
  displayName: 'Deploy To Production Env'
  dependsOn: QA # this was changed from Test to QA
....

Step 4: Include the new stage in your main pipeline file

I will now add the qa.yaml reference to azure-pipelines.yaml:

trigger:
- main

pool:
  vmImage: 'ubuntu-latest'

variables:
  solution: '**/*.sln'
  buildPlatform: 'Any CPU'
  buildConfiguration: 'Release'


stages:
- template: stages/build.yaml
- template: stages/test.yaml
- template: stages/qa.yaml
- template: stages/production.yaml

Step 5: Deploy and Watch Bicep Work Its Magic

Initiate the deployment process, just as you did previously. As Bicep processes the qa.json configuration, it will provision a brand-new resource group labeled for the QA environment.

Once the QA stage is complete the new environment will be up and running in Azure!

Wrapping Up

With a few simple configurations and Bicep's robust capabilities, you can dynamically create multiple environments tailored to specific needs. The era of tedious, manual provisioning is behind us!

What's next

In the next article, I will remove the staging slot from the QA environment to demonstrate how to add conditions in Bicep files. Feel free to subscribe to the newsletter below or follow me on Twitter if you'd like to be notified as soon as possible!

In the realm of Azure DevOps, infrastructure management via YAML files has become increasingly prominent. While this shift offers immense power, it can lead to lengthy and often complex azure-pipelines.yaml files. But what if there was a more structured, readable approach?

Today, we’ll unravel the art of breaking down a monolithic azure-pipelines.yaml into distinct files, each representing its own stage.

Why Break Down Your YAML?

• Readability: Smaller, function-specific files are easier to read, understand, and maintain, just like your code.

• Collaboration: Different teams can own different stages without stepping on each other's toes.

• Error Management: Isolating stages helps in pinpointing issues quickly.

Step-by-step Guide to Splitting Your YAML

1. Understand Your Existing Structure

• First, take stock of your current azure-pipelines.yaml. How is it structured? What stages exist, and what does each stage entail? I'll use the yaml from our sample project as an example:

trigger:
- main

pool:
  vmImage: 'ubuntu-latest'

variables:
  solution: '**/*.sln'
  buildPlatform: 'Any CPU'
  buildConfiguration: 'Release'
  location: 'westeurope'
  configFileName: 'prod.json'
  resourceGroupName: 'azure-devops-yaml-pipeline'
  stagingAppUrl: 'https://bogdan-todo-app-staging.azurewebsites.net/health'


stages:
- stage: build
  jobs:
    - job: BuildSolution
      steps:
      - task: DotNetCoreCLI@2
        displayName: 'Build .NET solution'
        inputs:
          command: 'build'
      - task: DotNetCoreCLI@2
        displayName: 'Create publish artifact'
        inputs:
          command: 'publish'
          publishWebProjects: false
          arguments: '-o $(build.artifactStagingDirectory)'
          zipAfterPublish: false
      - task: PublishPipelineArtifact@1
        displayName: 'Publish artifact'
        inputs:
          targetPath: $(build.artifactStagingDirectory)
          artifact: 'drop'
          publishLocation: 'pipeline'

- stage: test
  jobs:
    - job: RunUnitTests
      steps:
      - task: DotNetCoreCLI@2
        displayName: 'Run unit tests'
        inputs:
          command: 'test'
          projects: '**/*[Tt]est*/*.csproj'

- stage: update_infrastructure
  displayName: 'Deploy Bicep Infrastructure'
  jobs:
    - job: UpdateAzureResources
      steps:
        - task: AzureCLI@2
          displayName: 'Deploy Bicep Infrastructure'
          inputs:
            azureSubscription: 'AzureConnection'
            scriptType: 'pscore'
            scriptLocation: 'scriptPath'
            scriptPath: './infrastructure/deploy.ps1'                
            arguments: '$(resourceGroupName) $(location) $(configFileName)'

- stage: deploy_app
  displayName: 'Deploy To App Service'
  jobs:
    - job: deploy
      steps:
        - task: DownloadPipelineArtifact@2
          displayName: 'Download pipeline artifact'
          inputs:
            buildType: 'current'
            artifactName: 'drop'
            targetPath: '$(Pipeline.Workspace)/drop'
        - task: AzureWebApp@1
          displayName: 'Deploy to staging slot'
          inputs:
            azureSubscription: 'AzureConnection'
            appType: 'webAppLinux'
            appName: 'bogdan-todo-app'
            package: '$(Pipeline.Workspace)/drop'
            deployToSlotOrASE: true
            slotName: 'staging'
            resourceGroupName: $(resourceGroupName)
            runtimeStack: 'DOTNETCORE|7.0'
            startUpCommand: 'dotnet ToDoApp.Server.dll'      
        - task: AzureCLI@2
          retryCountOnTaskFailure: 3
          displayName: 'Check API health before swapping slots'
          inputs:
            azureSubscription: 'AzureConnection'
            scriptType: 'pscore'
            scriptLocation: 'scriptPath'
            scriptPath: './infrastructure/healthcheck.ps1'                
            arguments: '$(stagingAppUrl)'   
        - task: AzureAppServiceManage@0
          displayName: 'Swap slot'
          inputs:
            azureSubscription: 'AzureConnection'
            Action: 'Swap Slots'
            WebAppName: 'bogdan-todo-app'
            ResourceGroupName: $(resourceGroupName)
            SourceSlot: 'staging'

2. Create Distinct YAMLs for Each Stage

In the yaml file above we have 4 stages, so we can create these yaml files:

• build.yaml - for building the .NET solution

• test.yaml - for running the tests

• prod.yaml - for deploying the production infrastructure using Bicep and then deploying the app

Let's create them one by one, and we'll start with the build.yaml file:

stages:
- stage: Build
  jobs:
    - job: BuildSolution
      steps:
      - task: DotNetCoreCLI@2
        displayName: 'Build .NET solution'
        inputs:
          command: 'build'
      - task: DotNetCoreCLI@2
        displayName: 'Create publish artifact'
        inputs:
          command: 'publish'
          publishWebProjects: false
          arguments: '-o $(build.artifactStagingDirectory)'
          zipAfterPublish: false
      - task: PublishPipelineArtifact@1
        displayName: 'Publish artifact'
        inputs:
          targetPath: $(build.artifactStagingDirectory)
          artifact: 'drop'
          publishLocation: 'pipeline'

In the build.yaml file we build the project and then we publish it as an artifact that will be used in the later stages.

The test.yaml file looks like this:

stages:        
- stage: Test
  dependsOn: Build
  jobs:
    - job: RunUnitTests
      steps:
      - task: DotNetCoreCLI@2
        displayName: 'Run unit tests'
        inputs:
          command: 'test'
          projects: '**/*[Tt]est*/*.csproj'

In this stage we are just running the unit tests. At the beginning of the file, you'll observe the use of the dependsOn keyword. This instructs the pipeline to wait for the completion of the Build stage before proceeding.

The last one is production.yaml:

stages:
- stage: Production
  displayName: 'Deploy To Production Env'
  dependsOn: Test
  variables:
    location: 'westeurope'
    configFileName: 'prod.json'
    resourceGroupName: 'azure-devops-yaml-pipeline'
    stagingAppUrl: 'https://bogdan-todo-app-staging.azurewebsites.net/health'
  jobs:
    - job: UpdateAzureResources
      steps:
        - task: AzureCLI@2
          displayName: 'Deploy Bicep Infrastructure'
          inputs:
            azureSubscription: 'AzureConnection'
            scriptType: 'pscore'
            scriptLocation: 'scriptPath'
            scriptPath: './infrastructure/deploy.ps1'                
            arguments: '$(resourceGroupName) $(location) $(configFileName)'
    - job: Deploy
      dependsOn: UpdateAzureResources
      steps:
        - task: DownloadPipelineArtifact@2
          displayName: 'Download pipeline artifact'
          inputs:
            buildType: 'current'
            artifactName: 'drop'
            targetPath: '$(Pipeline.Workspace)/drop'
        - task: AzureWebApp@1
          displayName: 'Deploy to staging slot'
          inputs:
            azureSubscription: 'AzureConnection'
            appType: 'webAppLinux'
            appName: 'bogdan-todo-app'
            package: '$(Pipeline.Workspace)/drop'
            deployToSlotOrASE: true
            slotName: 'staging'
            resourceGroupName: $(resourceGroupName)
            runtimeStack: 'DOTNETCORE|7.0'
            startUpCommand: 'dotnet ToDoApp.Server.dll'      
        - task: AzureCLI@2
          retryCountOnTaskFailure: 3
          displayName: 'Check API health before swapping slots'
          inputs:
            azureSubscription: 'AzureConnection'
            scriptType: 'pscore'
            scriptLocation: 'scriptPath'
            scriptPath: './infrastructure/healthcheck.ps1'                
            arguments: '$(stagingAppUrl)'   
        - task: AzureAppServiceManage@0
          displayName: 'Swap slot'
          inputs:
            azureSubscription: 'AzureConnection'
            Action: 'Swap Slots'
            WebAppName: 'bogdan-todo-app'
            ResourceGroupName: $(resourceGroupName)
            SourceSlot: 'staging'

In this file, we have combined two previous stages: infrastructure deployment and deployment to the app service. The Production stage depends on the Test stage, so if your tests pass then we won't deploy our code to the production environment.

We have also relocated some variables from the azure-pipelines.yaml to this file, making them accessible to all the jobs within the Production stage.

One last thing I should mention is that jobs run in parallel, so I added the dependsOn clause to the Deploy job, this means that we will only deploy after the infrastructure deployment is finished successfully.

3. Reference these files within the main YAML

I will now move these files to a folder called stages and reference them like this in the azure-pipelines.yaml:

trigger:
- main

pool:
  vmImage: 'ubuntu-latest'

variables:
  solution: '**/*.sln'
  buildPlatform: 'Any CPU'
  buildConfiguration: 'Release'


stages:
- template: stages/build.yaml
- template: stages/test.yaml
- template: stages/production.yaml

That's it for now! We've successfully split our YAML into individual stages making it cleaner and easier to read and navigate.

The code is public and you can find it here: https://dev.azure.com/bujdea/_git/AzureDevopsYamlPipeline

Conclusion

In conclusion, just as we emphasize writing clean, concise, and readable code, the same principles should be applied to our YAML files in Azure DevOps pipelines. Keeping our YAML configurations compact and straightforward not only ensures better maintainability but also reduces the potential for errors and facilitates collaboration. Let's treat our infrastructure definitions with the same care and attention to detail as our application code, striving for clarity and simplicity in every line.

What's next

In the next article, I will add a new environment to our sample application in 5 simple steps. Feel free to subscribe to the newsletter below or follow me on Twitter if you'd like to be notified as soon as possible!

In our last article, we explored the slot-swapping technique in Azure Pipelines. While swapping provides us with seamless deployments, how do we ensure that the newly deployed code in the staging slot is healthy and ready for production? The answer: Health Checks. This article uncovers the importance and implementation of health checks in .NET applications, ensuring that we can confidently swap our slots without unexpected hiccups.

Why Health Checks?

Imagine deploying a new release to your staging environment. You swap the slots, and suddenly, users are facing issues. You'd wish there were a mechanism to catch these glitches before the switch. That's where health checks come in.

At its core, health checks provide an automated way to verify if your application is functioning correctly after a new deployment. They can test various parts of your system and ensure that they're not just alive but well.

Creating a custom Health Check

Before diving deep, let's start with a simple custom health check in a .NET application. This check will randomly return a health status:

public class ToDoAppHealthCheck : IHealthCheck
{
    public Task<HealthCheckResult> CheckHealthAsync(HealthCheckContext context, CancellationToken cancellationToken = new CancellationToken())
    {
        try
        {
            var todoService = new ToDoService();
            if (todoService.IsUpAndRunning())
            {
                return Task.FromResult(HealthCheckResult.Healthy("The ToDO service is up and running"));
            }

            return Task.FromResult(HealthCheckResult.Degraded("The ToDo service has issues"));
        }
        catch (Exception e)
        {
            return Task.FromResult(HealthCheckResult.Unhealthy("The ToDo service is having issues", e));
        }
    }
}
...
// this is the method from the ToDoService which sends a random status
public bool IsUpAndRunning()
        {
            var status = DateTime.UtcNow.Millisecond % 3;
            switch (status)
            {
                case 0:
                    return true;
                case 1:
                    return false;
                default:
                    throw new Exception("Service is down");
            }
        }

This is not a practical health check but serves as a simple example to get us started.

To enable health checks in our app we have to add these lines to Program.cs:

builder.Services.AddHealthChecks()
    .AddCheck<ToDoAppHealthCheck>("ToDoApp");
...
app.MapHealthChecks("/health");

If you start your app and go to the /health endpoint you'll notice that the response is a string with one the following values: "Healthy", "Degraded" and "Unhealthy". This is fine but I like more details so I'm sending a JSON instead, and for this you need to add a parameter to the MapHealthChecks function like this:

app.MapHealthChecks("/health", new HealthCheckOptions
{
    ResponseWriter = async (context, report) =>
    {
        var result = new
        {
            status = report.Status.ToString(),
            entries = report.Entries.Select(e => new
            {
                key = e.Key,
                status = e.Value.Status.ToString(),
                description = e.Value.Description,
                duration = e.Value.Duration,
                exception = e.Value.Exception?.Message
            })
        };

        await context.Response.WriteAsJsonAsync(result);
    }
});

Now the response will look like this:

{
    "status": "Unhealthy",
    "entries": [
        {
            "key": "ToDoApp",
            "status": "Unhealthy",
            "description": "The ToDo service is having issues",
            "duration": "00:00:00.0002569",
            "exception": "Service is down"
        }
    ]
}

Azure Pipeline: Triggering Health Check

For our Azure Pipeline, we'll implement a YAML step that runs a PowerShell script. This script will make a web request to the /health endpoint and verify the application's health status.

This is the YAML code for calling the script:

- task: AzureCLI@2
  retryCountOnTaskFailure: 3
  displayName: 'Check App health before swapping slots'
  inputs:
    azureSubscription: 'AzureConnection'
    scriptType: 'pscore'
    scriptLocation: 'scriptPath'
    scriptPath: './infrastructure/healthcheck.ps1'                
    arguments: '$(stagingAppUrl)'

This task will invoke the script below and it will retry a maximum of 3 times. If the script fails 4 times then the pipeline won't proceed and our staging slot won't be swapped with the production one.

param (
    $stagingApiUrl
)
Start-Sleep -Seconds 5

Write-Host "Health check for $stagingApiUrl"

$response = Invoke-WebRequest -Uri $stagingApiUrl -UseBasicParsing -ErrorAction SilentlyContinue
if ($null -eq $response) {
    $statusCode = $Error[0].Exception.Response.StatusCode.Value__
    $reader = New-Object System.IO.StreamReader($Error[0].Exception.Response.GetResponseStream())
    $content = $reader.ReadToEnd() | ConvertFrom-Json
} else {
    $statusCode = $response.StatusCode
    $content = $response.Content | ConvertFrom-Json
}

if ($statusCode -eq 200 -and $content.status -eq "Healthy") {
    Write-Host $response.Content    
} else {
    Write-Host "API health check failed with status code: $statusCode and health status: $($content.status)"
    exit 1
}

This script could have been much shorter, but it isn't too complicated. Let me explain what it does.

First, the script waits for 5 seconds at startup. This is because just prior to this task, we deployed our code to the staging slot, and it might take some time for the staging slot to be ready to serve requests. Until that occurs, the app will return a 502 error, so we need to account for this. The time it takes to be ready can vary depending on the tier of your app service and what you have deployed. For instance, if you're running migrations at startup, the code is deployed, but the app won't serve requests until the migrations have been applied. As a result, it will return a 502 error for every request until the process is complete, like this:

After the 5-second interval, the script sends a request to our staging slot's /health endpoint, which in our case is https://bogdan-todo-app-staging.azurewebsites.net/health.

We then obtain the status and content of the response. To proceed with the swap, we need the status code to be 200 and the health check status to be Healthy. Of course, this can be adjusted; perhaps you are comfortable with a Degraded status as well. However, it's up to you to decide.

The /health endpoint will return a JSON that looks like this:

{
    "status": "Unhealthy",
    "entries": [
        {
            "key": "ToDoApp",
            "status": "Unhealthy",
            "description": "The ToDo service is having issues",
            "duration": "00:00:00.0002569",
            "exception": "Service is down"
        },
        {
            "key": "ExternalAPI",
            "status": "Healthy",
            "description": null,
            "duration": "00:00:00.0000015",
            "exception": null
        }
    ]
}

There's an overall status and then each health check has its own status. That's why it's up to you whether you want to check only the overall status or focus on specific services. For instance, I might have a health check for Google Analytics that I can ignore because it's not critical for my app, but I really need the Stripe API to be up and running, so I'll base my decision on that.

Health checks in real-world applications

The example provided earlier serves as a basic introduction. Now, let's delve into the practical application of health checks in robust, real-world scenarios. In my ongoing project, I employ a combination of custom and predefined health checks. For instance, I've developed a custom health check for an external API. Despite having unit and integration tests for this API, they don't directly interact with it. Directly calling an external API from unit tests isn't justifiable. While our integration tests are responsible for contract testing, they don't communicate with the external API either. Instead, we ensure that the sent data adheres to the correct format and the expected response is received. But this doesn't guarantee full-proof coverage, and that's where the importance of health checks is underscored.

Imagine a scenario where a newly committed change unintentionally introduces a bug—say, it's related to retrieving API credentials from an Azure Key Vault. This glitch may remain unnoticed until deployment. Fortunately, our health checks are designed to flag such issues prior to the staging slot being swapped with production.

Configuring health check monitoring in Azure

Azure App Services offers the flexibility to consistently monitor the /health endpoint. This monitoring can be set at specific intervals, coupled with the provision to set up alerts for anomalies. Consider a situation where post-deployment, someone modifies the credentials in the Key Vault. In such instances, an immediate alert can assist in swift remediation. Similarly, if the external API faces downtime due to reasons beyond your control, it's beneficial to be aware. This not only aids in timely communication with stakeholders but also reassures them of your system's integrity.

This is how you configure health check monitoring in Azure:

1. Open the app service in Azure and go to Monitoring -> Health check

   

2. Select Enable and provide a valid URL path, in our case it's /health

3. Select Save.

To define an alert you have to click on Metrics on the same screen, and then click on New alert rule

I won't delve into the details, as that could warrant a separate blog post, which I might consider writing later. For now, it's crucial to comprehend that by enabling health checks you can prevent issues from going into production or at least you can get notified when something bad happens.

Using predefined health checks

If you're using certain Azure services there are predefined health checks for them. For example, if you're using SQL Server with Entity Framework then you can install the package Microsoft.Extensions.Diagnostics.HealthChecks.EntityFrameworkCore and all you have to do is to add this line in your Program.cs

services.AddHealthChecks()
        .AddDbContextCheck<MyDbContext>();

This health check will test the connectivity and you can even pass a test query that will be executed.

There's a predefined health check for Azure Key Vault as well, you just need the Nuget package AspNetCore.HealthChecks.AzureKeyVault and here's how we use it:

services.AddHealthChecks()
         .AddAzureKeyVault(
              new Uri(configuration["KeyVaultUri"]),
              new DefaultAzureCredential(new DefaultAzureCredentialOptions()),
              setup => { setup.AddSecret("externalApiClientSecret"); });

The AddAzureKeyVault method accepts an action that allows interaction with the Key Vault. In our case, we not only test the connection to the Key Vault but also verify if our API can add a secret. If someone accesses the Key Vault and revokes the permission to create secrets, our health check will alert us to this issue. Pretty cool, right?

Best Practices for Health Checks

1. Broad Coverage: Health checks should be comprehensive. It's not just about the application being up, but whether all its dependencies (like databases, external services) are responsive.

2. Speed Matters: Health checks should be quick. Lengthy checks can delay deployments and might lead to timeouts.

3. Isolation: Ensure health checks don't affect the system's state. They should be idempotent.

4. Detailed Reporting: While a simple 'Healthy' or 'Unhealthy' might be okay for basic checks, having detailed reports can be invaluable during failures to trace back the issue.

5. Regular Monitoring: Instead of only using them during deployments, integrate health checks into monitoring tools for continuous feedback.

Wrapping Up

I think we can agree that health checks play a vital role in ensuring our applications are not only up but functioning correctly. By integrating these checks into our pipeline, we get an extra layer of validation before the swap, leading to more robust deployments.

The code for this app can be found here: https://dev.azure.com/bujdea/_git/AzureDevopsYamlPipeline

In the next article, we will add another layer of complexity and robustness by introducing another environment using Bicep. There, we'll focus on running end-to-end tests on this new environment while keeping our production environment's checks concise and efficient. Stay tuned and keep deploying with confidence!

Production issues causing downtime are a nightmare for developers, yet few consider the downtime resulting from new releases. Typically, companies attempt to identify periods with the lowest customer activity, send advance notifications about the upcoming release and its inevitable downtime, and consider it normal. However, I prefer utilizing blue-green deployment to achieve zero downtime. At its core, it's about having two production environments: one that's live ('blue') and one that's idle ('green'). When we want to release a new version of our app, we deploy it to the idle environment, test it out, and once confident, switch traffic to this new environment, either all at once or only to a few customers.

In this manner, customers won't notice that just a moment ago they were browsing the old version, and now they are on the new one, even during peak traffic hours. Sounds promising, right? Let's explore how we can implement this using App Service Slots.

Blue-green deployment using Azure App Service Slots

Azure App Service slots allow us to host multiple versions of a web app. Think of them like parallel universes for your app. For instance, in my ASP .NET Web API project, when I push changes, I deploy them to a staging slot first. It mirrors my production environment, ensuring everything works perfectly. Then, with the mere click of a button (or a few lines in the YAML pipeline), I swap the staging slot with the production one.

Let's see some code to understand this better. When you're directly deploying to an App Service this is how the YAML looks like:

- stage: deploy_app
  displayName: 'Deploy To App Service'
  jobs:
    - job: deploy
      steps:
        - task: DownloadPipelineArtifact@2
          displayName: 'Download pipeline artifact'
          inputs:
            buildType: 'current'
            artifactName: 'drop'
            targetPath: '$(Pipeline.Workspace)/drop'
        - task: AzureWebApp@1
          displayName: 'Deploy to app service'
          inputs:
            azureSubscription: 'AzureConnection'
            appType: 'webAppLinux'
            appName: 'bogdan-todo-app'
            package: '$(Pipeline.Workspace)/drop'
            startUpCommand: 'dotnet ToDoApp.Server.dll'      
            runtimeStack: 'DOTNETCORE|7.0'

The second task handles the deployment; however, during blue-green deployments, we aim to deploy to a staging slot first and then swap it with the production slot. To achieve this, we must initially create a slot for our app service.

Creating a deployment slot in Azure

Not all app service plans support deployment slots. If you have a plan lower than S1, you will encounter this message when clicking on "Deployment Slots" within your App Service.

Either click on upgrade or go to the "Scale up" section and ensure that you're on a tier that has deployment slots.

Once you did that, go to "Deployment slots" and click on "Add slot":

You will notice that there's already a slot called "PRODUCTION", so we will add our "STAGING" slot now. I'll call my slot "staging" and click on "Add" at the bottom of the drawer:

That's easy, but in the last post we went over Bicep infrastructure deployment, so I want to show you how to do it with Bicep as well:

Creating a deployment slot using Bicep

It's actually pretty simple, we just need to add a webAppSlot resource to our app.bicep file:

resource webAppSlot 'Microsoft.Web/sites/slots@2022-03-01' = {
  name: 'staging'
  location: location
  kind: 'app,linux'
  parent: webApp
  properties:{
    enabled: true
    httpsOnly: true
    siteConfig: {
      httpLoggingEnabled: true
      linuxFxVersion: 'DOTNETCORE|7.0'
    }
  }
}

If we push this then the pipeline will take care of applying the infrastructure updates and our slot will be created.

When the staging slot is created you will have two instances of your API running in parallel. In my case, one is bogdan-todo-app.azurewebsites.net (production) and the other one is bogdan-todo-app-staging.azurewebsites.net (staging)

Next, we'll deploy our app to the staging slot and then swap it with production.

Deploy to a staging slot from Azure Pipelines

Let me first show you the entire deployment stage and then I'll talk about what's happening:

- stage: deploy_app
  displayName: 'Deploy To App Service'
  jobs:
    - job: deploy
      steps:
        - task: DownloadPipelineArtifact@2
          displayName: 'Download pipeline artifact'
          inputs:
            buildType: 'current'
            artifactName: 'drop'
            targetPath: '$(Pipeline.Workspace)/drop'
        - task: AzureWebApp@1
          displayName: 'Deploy to staging slot'
          inputs:
            azureSubscription: 'AzureConnection'
            appType: 'webAppLinux'
            appName: 'bogdan-todo-app'
            package: '$(Pipeline.Workspace)/drop'
            deployToSlotOrASE: true
            slotName: 'staging'
            runtimeStack: 'DOTNETCORE|7.0'
            startUpCommand: 'dotnet ToDoApp.Server.dll'      
        - task: AzureAppServiceManage@0
          displayName: 'Swap slot'
          inputs:
            azureSubscription: 'AzureConnection'
            Action: 'Swap Slots'
            SourceSlot: 'staging'
            WebAppName: 'bogdan-todo-app'

First, we're not deploying to the app service directly anymore, instead, we're deploying to the staging slot. To do this we've added these two lines:

    deployToSlotOrASE: true
    slotName: 'staging'

Then, once the deployment is done, we need to swap the slots. This means that traffic from production will be redirected to the staging slot and staging will become the new production. For this we're going to use the 'Swap Slots' action like this:

Action: 'Swap Slots'
SourceSlot: 'staging'

Now your app was upgraded to a new version without any downtime! The full code is in this repository: https://dev.azure.com/bujdea/_git/AzureDevopsYamlPipeline and you can also access the pipeline:

Wrapping Up

By utilizing blue-green deployments with App Service slots, we can achieve zero-downtime releases and ensure users experience seamless transitions between app versions.

Azure App Service slots, in conjunction with Azure DevOps YAML pipelines, have made blue-green deployments incredibly easy for my team. Naturally, this is just a basic demonstration of deployment slots, but in future articles, we will delve into more advanced scenarios such as health checks, deployment slot settings, and more.

What's Next?

In the next article, I'll showcase how to incorporate health checks into our Azure DevOps pipeline. This ensures that we only swap slots when our deployment is successful, adding another layer of confidence to our release process.

Why deploy infrastructure using Bicep?

I won't cover all the advantages of this approach, but I'll highlight the two most important ones for me. First, you can treat your infrastructure as code and store it in a repository, allowing you to approve changes and track its progress over time. Second, automation becomes possible, as you can easily deploy Bicep files instead of manually creating and configuring resources in Azure. For instance, if you need another environment for your project, you can quickly create it with minor adjustments to your Bicep code. We'll discuss all of this in detail throughout the article.

Preparing Azure DevOps for Bicep deployment

Before our pipeline can make Azure deployments we first need to create a service connection to Azure. For this, go to project settings and then click on "Service connections":

Now, choose the option labeled "Azure Resource Manager" and click on "Service principal (automatic)." Proceed by clicking "Next," and upon completing the wizard, your service connection will be established.

Writing the Bicep code

Our next step is to write the Bicep code which will create our app service and app service plan.

I won't turn this blog post into a Bicep tutorial, but I will write another post to provide some tips for getting started. For now, I'll assume that you know how to write Bicep or at least understand some basic YAML, as we're not dealing with complicated tasks.

When we're working with Infrastructure as Code (IaC), especially with more complex setups, it's crucial to maintain clarity and organization. Bicep lends itself brilliantly to modular designs so it's easy to understand why our Bicep code will be separated into two files: main.bicep and app.bicep

main.bicep can be seen as the entry point or the orchestrator of our infrastructure deployment. It's where we define which modules or sets of resources should be deployed. By referencing other Bicep files (like app.bicep), the main file allows us to break apart our infrastructure into manageable chunks or modules, giving us the freedom to combine, reuse, or extend them as needed.

param location string = resourceGroup().location
param appName string
param appSku string

module app 'app.bicep'  = {
  name: 'bogdan-todo-app'
  params:{
    location: location
    appName : appName
    appSku: appSku
  }
}

The app.bicep file is dedicated to defining the resources specifically needed for the Blazor app component of our application. By keeping the definition of our app infrastructure separate in app.bicep, we achieve a few things:

• Clarity: It's immediately clear what resources this file defines without mixing it up with other unrelated resources.

• Reusability: If we were to deploy another similar app or service in the future, having a dedicated file makes it much easier to replicate or make slight modifications without reinventing the wheel.

• Scalability: As our app's infrastructure grows in complexity, having a dedicated file allows us to manage that complexity without cluttering our main deployment script.

This is the code for our app, it's pretty simple but in future articles we're going to expand it by adding app settings, connection strings, slots, managed identities, etc.

param location string = resourceGroup().location
param appName string
param appSku string = 'S1'

resource asp 'Microsoft.Web/serverfarms@2022-03-01' = {
  name: '${appName}-app-plan'
  location: location
  sku: {
    name: appSku
  }
  kind: 'linux'
  properties:{
    reserved: true
  }
}

resource webApp 'Microsoft.Web/sites@2022-03-01' = {
  name: '${appName}-app'
  location: location
  identity: {
    type: 'SystemAssigned'
  }
  kind: 'app,linux'
  properties: {    
    serverFarmId: asp.id
    httpsOnly: true
    siteConfig: {
      httpLoggingEnabled: true
      linuxFxVersion: 'DOTNETCORE|6.0' 
    }
  }
}

As you can see, the app.bicep file has 3 parameters: location, name and SKU. I'm using the same location as the resource group for simplicity, and the appName and appSku come from the main module, which in turn receives them from a configuration file.

The configuration (called prod.json) file looks like this:

{
    "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentParameters.json#",
    "contentVersion": "1.0.0.0",
    "parameters": {
      "location": {
        "value": "westeurope"
      },
      "appName": {
        "value": "bogdan-todo"
      },
      "appSku": {
        "value": "S1"
      }
    }
  }

If I decide to create another environment in the future I just need to create another json file. For example, let's say I want to create a "dev" environment, so I'll create a dev.json file where I can simply change the appName to something like bogdan-todo-dev and choose a lower appSku if I want to reduce costs for that environment. As you can see, creating new environments becomes quite easy once this is set up.

Running the Bicep deployment from a YAML pipeline

To deploy these Bicep files I'm going to write a Powershell script which will get executed in the pipeline. The script looks like this:

[CmdletBinding()]
param (
    $resourceGroupName,
    $location,
    $configFileName
)

az group create --name $resourceGroupName --location $location
az deployment group create --resource-group $resourceGroupName --template-file ./infrastructure/main.bicep --parameters ./infrastructure/environments/$configFileName

Now let's show the pipeline code as well:

trigger:
- main

pool:
  vmImage: 'ubuntu-latest'

variables:
  solution: '**/*.sln'
  buildPlatform: 'Any CPU'
  buildConfiguration: 'Release'
  location: 'westeurope'
  configFileName: 'prod.json'
  resourceGroupName: 'azure-devops-yaml-pipeline'

# build and test stage skipped for now

- stage: update_infrastructure
  displayName: 'Deploy Bicep Infrastructure'
  jobs:
    - job: UpdateAzureResources
      steps:
        - task: AzureCLI@2
          displayName: 'Deploy Bicep Infrastructure'
          inputs:
            azureSubscription: 'AzureConnection'
            scriptType: 'pscore'
            scriptLocation: 'scriptPath'
            scriptPath: './infrastructure/deploy.ps1'                
            arguments: '$(resourceGroupName) $(location) $(configFileName)'

# app service deployment at the end

This stage updates the infrastructure every time it is executed. Since our script requires permission to interact with Azure, we must provide the name of our service connection in the azureSubscription parameter. Next, we specify the script's path and supply it with some arguments. With everything set up, let's push our code to Azure and observe how it functions.

One other step we have to do is to allow our service connection to be used by this pipeline, so click on View:

And then click on Permit:

When you first use Bicep to deploy your infrastructure, every resource defined in your Bicep file is new to Azure. As a result, Azure needs to provision each of these resources from scratch. Depending on the nature and number of resources you've defined, this can be an intricate process involving multiple steps, dependencies, and configurations. Naturally, this initial setup tends to take the longest as everything is created anew.

After your resources have been initially set up, any subsequent deployments or updates with Bicep are processed differently. Bicep is designed to be idempotent, meaning it aims to achieve a desired state without redundant operations. In other words, if a resource already exists in the desired state, Bicep won't waste time recreating it.

When you make changes to your Bicep files and deploy again, Bicep will first evaluate the current state of the resources in Azure. It then intelligently determines what has changed since the last deployment. Only these changes are applied, making the process faster and more efficient. This not only saves time but also reduces the potential for errors or disruptions since unchanged resources remain untouched.

Code sample

The complete code and the pipeline can be found in a public Git repository. Feel free to experiment with it and deploy it to your own Azure subscription if you wish. Just make sure to update the service connection name and the app name.

Wrapping Up

For me, it's amazing how easy it is to deploy our infrastructure from Azure DevOps using Bicep. The ease of setting up new environments stands out, and having most of the process automated saves a good chunk of time and cuts down on manual errors.

In the next article, we'll dive a bit deeper, exploring blue-green deployment with Azure App Service slots. So, stay tuned and happy coding!

I'll discuss how I secured my first job, the reasons behind quitting my jobs, the successes I achieved, and the failures I encountered.

Another motivation for doing this is that I enjoy hearing about other people's experiences firsthand. While reading about soft skills theory is informative, I find that I prefer engaging stories, so I'd like to share a few of my own!

Story #1 - How I landed my first job

I think I applied to dozens of interviews in my first 2 years of university, but when I finally got to one of them it seemed like a match made in heaven. The good thing about going to a lot of interviews is that I wasn't that scared of them anymore. After my ~20th interview I had no more sweaty palms, I knew most of the questions and answers to lame questions like "Where do I see myself in 5 years" or "How do I fit an elephant into a fridge", etc. I got through IQ tests, psychological evaluations, HR interviews, quizzes, leet code, team interviews, etc..... but the final interview was the one where I knew I got in before it ended.

In fall of 2012, I joined the Microsoft Student Partner program, which I think has since been renamed to Microsoft Learn Student Ambassadors. Through this program, I could freely access the latest Microsoft technologies and conduct hands-on labs to share my knowledge with peers. A highlight of the program was participating in a Windows 8 hackathon in October 2012. I had dabbled with the Windows 8 SDK a bit before that and even got a simple sound recorder app into the store. The hackathon was a blast — coding late into the night, pizza, drinks, and some solid memories. Even though I didn't snag a cash prize, I made some invaluable connections, particularly with a couple of the jury members. Fast forward a week, and I found myself walking into an interview room at Thinslices for a Windows 8 internship. And guess who I saw? Those same jury members because they were Thinslices employees! We chatted about the hackathon, my app, and I learned I was the only candidate with an app already in the Microsoft Store. About 15 minutes in, I had a hunch I might get the spot. Not long after, they confirmed it — and just like that, my tech journey truly began.

A short version of the events leading up to my first job would look like this:

• Failed many interviews

• Got involved in the community (Microsoft Student Partners)

• Started to learn about Windows 8 and published an app to test my knowledge

• Attended a hackathon and made connections

• Passed my first interview and got the internship

Conclusion

Get involved in the community and make connections

This isn't the only time I'll say this, as I have numerous stories from my experiences that led me to the same conclusion. However, for now, it's evident why I believe it's crucial to put yourself out there, participate in events, join communities, volunteer, present something, and so on. Some might argue that I was merely fortunate, but I believe that you create your own luck.

If I wasn't a Microsoft Student Partner I couldn't attend that hackathon, and I also wouldn't have known anything about Windows 8, much less develop something for it (let's face it, it wasn't that popular at its release because people still wanted to stay on Windows 7).

Some of you might argue that I could have landed another job simply by attending a different interview. Sure, that might be true, and I can't say whether my career would have been the same or not, but I do know that I genuinely enjoyed my time at Thinslices, and it was the ideal place for my first job. I'll share more about this in the next article!

This experience sparked a realization: ChatGPT has immense potential for fellow programmers, especially those in junior and mid-level positions. Recognizing that more developers could benefit from this AI tool, I felt inspired to share my insights and experiences with others.

At first, I thought I could write a series of articles but then I thought I could try something new, so I decided to write an ebook called "Programming with ChatGPT: 5 Steps to Future-Proof Your Career." This eBook aims to provide an eye-opening introduction to the possibilities of working with ChatGPT, offering practical guidance and techniques to help you make the most of it in your programming journey.

If you're curious about ChatGPT and how it can offer a new perspective on your programming career, I invite you to check out my book on Gumroad. I really think it's an opportunity to expand your horizons and see what this innovative tool has to offer. Here are the 5 chapters I wrote:

1. Chapter 1: Finding a Job with ChatGPT

2. Chapter 2: Onboarding 10x Faster with ChatGPT

3. Chapter 3: Enhancing Problem Solving and Debugging Skills with ChatGPT

4. Chapter 4: Code Optimization and Best Practices with ChatGPT

5. Chapter 5: Expanding Your Programming Knowledge with ChatGPT

The first 100 people can download it for free using this code: UX58P7D

I really hope you enjoy it!