/ Azure

Azure Bot Service - Continous Integration

Hot off the heels from my latest blog post on creating your first bot, I felt it was important to write another blog post focused on some governance/process when creating your bot.

Built straight into the Azure Bot Service (and Azure App Service more broadly), is a very simple Continuous Integration mechanism, allowing you to ensure that your latest code is available as soon as possible.

This approach may not be as rigorous as would be expected for a business critical enterprise solution but may be a good fit for "lone-wolf" developers, or smaller projects.

Firstly, jump back into the Azure Bot Service that you created previously, and navigate to the "Settings" tab.

Navigate to the Settings Tab of your Azure Bot Service

Once you expand the continuous integration section, you will be presented a link to download the latest code from your bot. Download, the source, extract it and initiate a repository.

Follow the steps to download the source code, and create a repository

I am opting to store the code on a Visual Studio Team Services (VSTS) repository, as it's my ALM tool of choice. I have navigated to my Visual Studio Team Services account and begun creating a project specifically for this bot project, as shown below.

Navigate to the Settings Tab of your Azure Bot Service

At this stage, I have code on my local machine and an empty git repository in my project in VSTS. It's time for me to get that code pushed up to the cloud.

Empty Visual Studio Team Services (VSTS) Repository

If you have not yet used Git in depth, I would recommend taking a look at some of the basics here.

There are a few commands that I am going to complete in my command line tool of choice, within the folder of my bot code.

  • Git init - This initialise my local folder as a Git repository on my local machine
  • Git add . - This adds a snapshot of all files/folders in my current directory to be staged (considered for versioning).
  • Git commit -am "Initial Commit" - We commit files/folders in the staging area by taking a snapshot to the local Git repository (i.e. database). In other words, permanently recording the changes in my version history.
  • Git remote add origin https://... - This adds a repository at a remote URLhttps://..., whereby changes can be pushed/pulled from your local repository.
  • Git push -u origin --all - This pushes all files from my local git repository to the upstream repository origin.

Git commands to setup local repository and push to VSTS

Great! Following these steps, we can now see that the repository is now in sync in the code section of Visual Studio Team Services.

Completion of Git commands, now showing files on VSTS

Now that we have setup our Source Control, we can now progress setting up our Continuous Integration. Click Configure Continuous Integration, and choose the source most pertinent to you. Of course, in the steps above - I have been planning to use Visual Studio Team Services. From the below screenshot, you can see there are many options.

Personally, I am not keen on using OneDrive or DropBox as a method of Version Control. I suppose this could work, by syncing a "local" git repository and sharing this between people. But there are some great solutions (e.g. VSTS / GitHub) readily available, which I would much prefer.

Azure Bot Service - Begin configuring Continuous Integration

If opting for Visual Studio Team Services, you will need to select the project to be linked, and which branch you will be watching. For demonstration purposes, I have chosen the master (main) branch.

Navigate to the Settings Tab of your Azure Bot Service

Once you have completed the input of your settings and click "OK", you will notice that the blade then begins pulling from your chosen source and triggers an update.

Navigate to the Settings Tab of your Azure Bot Service

There we go, you have now set up your Continuous Integration pipeline from the source that you chose. You will notice that when you navigate to the "Develop" tab, you are no longer able to edit the code in the Azure Portal, and can only change it by committing a change via your Source.

As mentioned earlier in this blog, this is a very light-weight approach - I would not expect to see this in an enterprise scenario. Instead, I would expect to see a Continuous Integration and Continuous Deployment pipeline, which contains automated tests (Unit, Integration, Load) and spans multiple environments (Dev/Test/UAT/Production).

Perhaps we could attempt a fuller pipeline in a future Blog post. But, for now - That's me! I hope that this has been useful. Further comments and thoughts welcome, please let me know on Twitter - @reddobowen.

Christian Reddington

Christian Reddington

Christian is enthusiastic about using technology to empower people and organisations. His current areas of interest include the Internet of Things, Data Science and DevOps.

Read More
Azure Bot Service - Continous Integration
Share this