I have a Microsoft Azure SQL Database project. I also have a Python3.9 project that uses unittest to unit test this database project. I have an Azure DevOps build pipeline defined in YAML that runs the unit test against the development-integration environment.
I do not want to publish changes to the development-integration environment before running the tests. If you think this is the wrong approach, I will consider your arguments.
I want to 'virtually' test the changes. I want to deploy the new objects to a temporary ad-hoc database instance. It must be equivalent to Azure Database Instance. When the tests have been executed I want to clear everything away. I do not want to deploy a database in Azure for this purpose due to billing, although if I were to use a serverless instance this would not be a problem.
Any ideas?
If you are on cloud and you need to test you need to test that on the cloud too.
You cannot "virtually" test, there is nothing equivalent to Azure SQL database on-prem.
Go with the serverless instance as you said.
Related
I originally felt this question was for Software Engineering, but they've closed it as off topic and sent me here, so here I am.
One of the biggest time sinks when doing the odd piece of DB development is setting up the environment locally, often my process goes like so:
Get database
Publish db server
Publish db
Load test data
Repeat for any dependencies (can go 3-4 levels deep)
This is a bit of a pain really, and can take a while, and I was thinking if there are any ways to automate this.
We make use of ADO, and through ADO we run builds that deploy our changes and load out test data to make sure we haven't broke anything. Now I imagine ADO follows a very similar process to myself like above, and reviewing the build it looks something like so:
Now, I'd love it if I could get access to the script that runs this, so that when I start development, it gets rid of all the above down-time of setting up the environment.
Does anyone know a way to do this? Or perhaps have any other recommendations?
No, it's unable to copy the build to run locally. They are all based on the existing tasks (see Build and release tasks and azure-pipelines-tasks ).
However, you can try to develop your own scripts by calling the corresponding tools for each step, then combine them together.
Alternately you could setup a private agent on your develop machine, then you can build with this private agent with that build definition.
Another way is setup a on-premise Azure DevOps server, thus you can export the definition from your Azure DevOps Service and import to the on-premise Azure DevOps server to use the definition directly.
As a part of my pipeline, I'd like to test my golang application in a step of my pipeline but it depends on a database. I have a docker-compose file with the database container and a container that applies the migrations to the database. At this point, I'd like to run the go tests.
How can I best achieve this with Azure Pipelines?
What's the best practice of migrating pentaho job/transformations from one server to another?
We've set up DEV, QA, UAT, Production PDI server with carte running on AWS. And developers in our team are using community edition to program and test locally with local carte service.
The servers are using database repository and local pcs are using file based repository.
Typically, when we migrate a transformation we will have to export xml and find those xml piece for that transformation/job and import into target servers.
I don't think this is a good practice, considering we are moving on CI/CD along with other java/js code.
Please advice a better way to do migration.
Thanks,
Martin
I think your issue is less about migrating from one server to another, and more about migrating from one repository type to another. Do you have a compelling reason to use different repository types?
We use file-based repositories for all environments, and a directory synchronization tool for migrations. We went with file-based repositories so our source control system could be used with it.
Would like to setup the CI system so that the integration tests could run in an centralized place.
How could we setup a database for each developer for their related branch of work.
We want to guarantee 100% compatibility with the deployed platform, at the cost of having multiple databases which is synchronized with a major db .
installation and data transfer should be automated and not painful during application build.
You have to setup database sandboxes for your CI server. This setup would depend a lot on what database solution you use and the size of your database.
we am using Jenkins hosted on Cloudbees for building our Github hosted code base. We would like to run an Integration Test pipeline for each build. For that, we need to create a MySQL DB before running the integration tests on Jenkins. Is there an easy way to create a MySQL DB as part of a Job in Jenkins, on Cloudbees?
Please look at the CloudBees DEV#cloud MySQL guide.
It covers configuring and starting a MySQL server that runs inside the build process.
A persistent MySQL server is typically more troublesome as you would need to clear out the tables prior to each test run.