We are trying to use Flyway for SQL Server and have a question regarding wildcards in .sql scripts. When deploying to our Dev, TST, and Prod environments, we make use of sql server synonyms and linked servers that are env specific. For example, when deploying to TST, the Linked Server and Synonym will point to SERVER_A, but Prod should point to SERVER_B. Is there a way for Flyway to automatically swap in the correct SERVER value depending on which environment we are deploying to at release time?
Related
I have a dockerized ASP.NET web api that I am running on AWS. I am planning on using RDS for the database, and I need to run migrations and I am unsure how I should go about this. My docker container only contains the dotnet runtime, so I can't just SSH into one of the machines and migrate. The RDS instance is set to only accept traffic from within the VPC, so I can't just run them from my machine. What would be the best way to run EF Core migrations into RDS?
I was thinking of maybe setting up a temporary EC2 machine, installing the dotnet SDK, EF Core and the source code, then running migrations and tearing it down. But I don't know if this is a good idea, or whether there is a better way.
A temporary EC2 instance for performing this sort of thing is fine, and a common practice.
I would suggest an alternative of building an AWS CodeBuild job to perform the migration task. However you might find your temporary EC2 instance useful for other things, like connecting to the database to perform ad hoc queries.
We have several Astronomer airflow deployments in production. Each deployment is based off its own git repo (some differences between each), however, they all use a core set of SQL scripts. Currently, if we need to update one of the core SQL scripts we need to update each and every airflow deployment (big pain and prone to copy paste errors).
Is there a way we can efficiently share these core SQL scripts in such a manner that we only need to update one repo and the changes are propagated to all deployments?
We have a similar requirement and we are deploying the SQL scripts and other metadata files in object storage, So you can have a seperate CI/CD job to deploy SQL scripts to Object Storage like AWS S3 or Azure Data Lake, and the processing system can read the SQL files and execute.
If there any changes in the SQL scripts then we can only deploy the SQL scripts to Object Storage.
I develop the code for my application against the Sandbox environment in Azure. my current appsettings.json file contains connection strings for Database, Azure Storage, etc which point to the Sandbox environment.
When the api is deployed through the DevOps pipeline to Dev, Staging and Production Env, the api should point to Database, azure Storage etc that are present in the respective environments Dev, staging and production.
I am trying to go with approach in Startup file
But I can't able to go further on the above to achieve this is in DevOps deployment.
You can achieve this by JSON variable substitution. For more information, refer here.
I have created an ASP.NET application which is deployed on Azure.
Every time whenever I want to publish it on Azure, I make use of a staging server to deploy and after testing everything on staging, I just swap both of them.
But there is a problem, I have some startup tasks that create some scheduled tasks for cron jobs. So, these task are also copied to production server from staging and cron jobs are run two times one on production and second in staging. But I want them only to run on production not on staging.
How can I prevent this duplicated cron job problem? Please give me some suggestions.
There is no easy way in order to distuinguish staging and production environments.
If I do remember correctly, you could use the Server Management REST Api to get more details about the current deployment. You just need to get the RoleEnvironment.DeploymentId and communicate with the REST Api by providing a valid X509 Certificate.
http://msdn.microsoft.com/en-us/library/windowsazure/ee460806.aspx
I'm corrently setting up our company DTAP environment for our ASP.NET web application. Current setup is like this:
Dev - on local machine with local developer db
Test - on our local company server with local company server DB
Acceptance - Production machine in separate IIS application, running a copy of production db
Production - Production machine on production DB
I want to add another environment in order to be able to reproduce bugs related to the data in the production db. I'm deploying everything using TeamCity and I'm looking for the easiest solution to download the production database (or a backup of it) to our company server and use if for a 'test on live data' environment.
What would be the recommended way to do this?
Right-click the database on the target server - "Tasks" - "Import data".
Specify your production server/tables as the source.