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.
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.
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.
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.
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.
Great! Following these steps, we can now see that the repository is now in sync in the code section of Visual Studio Team Services.
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.
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.
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.
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.