Most people have tried it. You are writing a script, which connects to a service using a user name and a password or you are using a Shared Access Service token to access insider builds from Microsoft and you just put the “secret” values right there in your source code. After all – it is only you who can access the data on your computer right? and you will of course remember to mask out these secrets if you ever need to share the script…
Well some times we forget and some times hackers to get access to files on your computer and suddenly you might have leaked data or secrets to public places, which you shouldn’t – or sometimes we don’t even realize that we have exposed a secret.
For quite some time, it has been possible to run automated tests in Docker using the Run-TestsInBcContainer function and it is my strong belief that this is used by a lot of partners today. Since 17.2, the Test Runner is available in Online Business Central Sandbox environments for installation from AppSource. From Extension Marketplace, you can install the Test Runner, open page 130451 and run your test manually. With BcContainerHelper 2.0.4 or later, you can also run tests in online sandbox environments, this blog post explains how.
There are 2 kinds of apps: AppSource Apps and Per Tenant Extensions (PTEs). These apps can be installed in two kinds of environments: Sandbox and Production. In Production, AppSource Apps are installed in the global scope and Per Tenant Extensions are installed in the Tenant Scope. In Sandbox environments you can also install apps to the development scope (like what VS Code does).
This blog post will describe how you can use BcContainerHelper 2.0.2 to install apps in any of those combinations.
When releasing the first version of Run-AlValidation in BcContainerHelper, i did a quick blog post about the function here. This blog post serves to explain some common scenarios of how to run the function. The blog post will also explain the parameters of Run-AlValidation a bit more in depth, for people to have a good chance of using the function before submitting for AppSource Validation.
The important part of this blog post: Please make sure to upgrade to BcContainerHelper 1.0.18 or reconfigfure the timestampServer in your existing version.
December 30th 2020 we got a number of apps for validation failing due to a wrong timestamp signature. Some partners discovered this before submitting and filed an issue on github here, complaining about this error: “The timestamp signature and/or certificate could not be verified or is malformed.“
I was enjoying a nice walk in the forest with my dogs, but my phone would reveal increased activity on github and emails from partners running into this strange issue.
On December 1st, I co-hosted a webinar about how people can make sure that their app passes AppSource Validation. Until now, I have always been preaching that people should run CI/CD and include AppSourceCop validation in their CI/CD pipeline, which is supported in the Run-AlPipeline function. But…, as I prepared for the session, it became evident that it would be really helpful to have a function, which basically does exactly the same as our validation pipeline.
For the last 2 years we have had the Hands On Lab (https://aka.ms/cicdhol) in a few iterations using Azure DevOps as the platform. Latest revision was published a few weeks ago.
There are however multiple platforms for DevOps out there and I wanted to investigate the functionality of Github, which also is part of the Microsoft family and probably the biggest provider of devops services to developers in the world.
Run-AlPipeline is a new function in BcContainerHelper. It has been in preview for a number of releases while being worked on, and a number of partners have already tried to use it. My apologies for changing things under your feet, but to my defense – I did write that the function was in preview.
With version 1.0.8 of BcContainerHelper, Run-AlPipeline is ready for real-life usage… (I think)
3 people (a biologist, a mathematician and a developer) were in Africa on a Safari. They drive by a blue elephant. The biologist shouts out: “Look, there is a BLUE elephant.”. The mathematician states: “Right you are, there is ONE blue elephant”. The developer slaps his palm against his forehead and says: “Damn, there are blue elephants…“