As more and more people move towards Business Central, people are also looking at Azure DevOps and not only for source control and Azure Pipelines, but also as a project management tool. So, I thought I would take the opportunity to talk a little bit about some of the corner stones in DevOps, because DevOps is not some fancy term that Microsoft has invented for the product, but it is a term used to cover a set of tools that can help you run a very lean software release cycle. In this post I will take you through the concept of dark releases 😱 

So, what are dark releases and why do we need them? 

The concept behind dark releases is that you release code to your production, without it being visible or enabled to all users, it is a way to let your super users test new functionality before you make it widely available, the difference behind doing it this way vs testing in a Test environment; is that by using dark releases you will let the users test on real data, and once it is accepted you would be able to make it widely available by setting a Boolean field to true in your setup 🙂. This kind of setup will let you make small releases to production and run an agile release cycle instead of doing a big bang implementation 🌪 and let us be honest; one of the most difficult things to do in software development is to get our users to test our solutions. But by using dark releases you are “forcing” your super users to test your code, and once they feel that it is ready, either a super user or a release manager can enable the code for everyone. 🤩 

So, in short dark releases are a way to create small releases and improve the stability of the code that will be released to the public by letting some super users test the code in production, and by doing so also removing the old “but it works in test” 🤨. And by allowing small releases you can also live up to the CI/CD way of thinking. 

To start using dark releases in BC / NAV you first need to setup a couple of things the first is that you need to create a setup table, this table should consist of a module name and an option field consisting of at least three options Not Active, Beta, Active. If you are using BC I would suggest that you use enums so your code would look something like this: 

The Modules Enum 

enum 50100 "RITModules" 
{ 
    Extensible = true; 
    value(0; "") 

    { 

        Caption = ''; 

    } 

    value(1; "Module 1") 

    { 

        Caption = 'Module 1'; 

    } 

    value(2; "Module 2") 

    { 

        Caption = 'Module 2'; 

    } 
} 

The Module Status Enum 

enum 50101 "RITModule Status" 

{ 

    Extensible = true; 

    value(0; "Not Active") 

    { 

        Caption = 'Not Active'; 

    } 

    value(1; Beta) 

    { 

        Caption = 'Beta'; 

    } 

    value(2; Active) 

    { 

        Caption = 'Active'; 

    } 

} 

The Modules table 

table 50100 "RITModules" 
{ 

    Caption = 'Modules'; 
    DataClassification = ToBeClassified; 

    fields 

    { 

        field(1; Module; Enum RITModules) 

        { 

            Caption = 'Module'; 
            DataClassification = SystemMetadata; 

        } 

        field(2; Status; Enum "RITModule Status") 

        { 

            Caption = 'Status'; 
            DataClassification = SystemMetadata; 

        } 

    } 

    keys 

    { 

        key(PK; Module) 

        { 

            Clustered = true; 

        } 

    } 

} 

The Page 

page 50100 "RITModules" 

{ 
    ApplicationArea = All; 
    Caption = 'Modules'; 
    PageType = List; 
    SourceTable = RITModules; 
    UsageCategory = Administration; 

    Layout 
    { 
        area(content) 
        { 
            repeater(General) 
            { 
                field(Module; Rec.Module) 
                { 
                    ApplicationArea = All; 
                } 

                field(Status; Rec.Status) 

                { 
                    ApplicationArea = All; 
                } 
            } 

        } 

    } 

} 

So, you would get something like this: 

Next you should add a new field to your user setup where you can setup if a user is a super user, once done it is important that you write the code in all your modules to check what status it has in the modules table, and to check if the current user can see modules in beta. 

Using this approach, it will also set a high standard for your code to be written as isolated as possible so you can encapsulate everything in if statements.  

I hope this post, got you a little bit more confident with using dark releases and I know it might be a big mouthful for many people to start writing the code so isolated, but once you get into the habit it really is a great way to structure your code, well that was it for this post, stay safe. 😷 

Leave a Reply