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.
Related
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.
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.
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.
Does anyone have any advice or techniques for deploying SSIS packages to the Integration services database.
Basically I maintain a number of SSIS packages that need to get deployed to several environments (dev, test and production), there is a need to change the individual database connections as well.
I would like to automate the process of deploying them to these environments, so it can be included in a full application deployment that can be done by the server admins.
I came up with a method for configuring packages for different environments using a single SQL Server configuration table (assuming all environments can connect to the configuration server).
http://www.sqlservercentral.com/articles/SSIS/66426/
If we have 3 developers working on the same Biztalk project what is the best way to set up our development environment?
We are using TFS to store the Biztalk project.
Should we use 1 sql server and 1 Biztalk server and then have 1 or more developer machines that access the sql and biztalk servers? The issue we get with this is when 1 developer compiles and deploys their changes it can effect other developers if they are also trying to compile and deploy their work.
Should we have each developer host their own complete sql and biztalk server for local development either on their machine or within their own virtual machine? The problem we find with this is that each developer could modify their server settings and those settings are not stored in source control. This can cause confusion when changes are deployed to a testing server. Another smaller issue is that each developer would need to have sql server, biztalk server and windows server installed.
Is there another way to set up a multiple developer biztalk development environment?
You will always want to have each developer have a complete BizTalk installation on their own machines. Believe me, it doesn't work otherwise, as you'll just keep getting on each other while trying to deploy/test/debug changes.
That said, you will also want a centralized dev/test environment where you deploy your code for more complete integrated testing and making sure all the changes from everyone are seen together.
Your point about configuration is true, but only up to a point. This is because you should make your solution configuration part of your source code and keep it in source control as well. This is particularly important once you're a bit ahead in your development as you'll need to start maintaining multiple versions of your binding files for each environment (dev, test, production and so on).
tomasr is right. Also, if you have decent hardware and lots of RAM, you may want to setup a VM image of your full developer environment, then share this will all your team. Not as fast as native hardware, but does allow you to roll back changes, replace your VM if you really mess up and everyone then has the same environment – ideally close to the target one.
Setting up a continuous build server is also a most, if your projects are small, you can get each checkin to cause a full build, BizTalk deploy, export of MSI and then run tests. Later as your solutions get more numerous you might have to move to a continuous build of C# changes only, then say nightly or several times a day, you do a full. We have done this with CruiseControl.net, Nant, nunit and various power shell scripts, it was pretty time consuming, but each morning we come to work to find a fully compiled, deployed, exported and tested set of BizTalk solutions ready for the test team.