We have two GCP projects - one for UAT environment and one for Prod environment. There are separate PostgreSQL instances in both the projects. How do I migrate relevant data from one SQL instance on GCP QA project to the other instance on GCP UAT project.
Business users would like to add data in UAT environment using an interface, do some testing and move the data to prod environment once it is approved in UAT.
Please provide suggestions.
Related
I have a pipeline that deploys the application. And I have multiple environments where it might be deployed. These deployments are not subsequent. Rather there is several development or test environments where features in development are tested in parallel, and potentially several production environments for different customers with different feature sets. So the advice from Azure DevOps multi-stage pipeline deployment to specific environment to create multi-stage pipeline is not appropriate, as the environments are unrelated.
Obviously, the deployment to any of the environments is exactly the same except for a handful of parameters that can either be derived from the name (like URL) or read from the environment itself.
Also the environments will be created over time, co the fewer steps it takes, the easier – creating a new environment means just creating a Kubernetes namespace, a database and a handful Azure resources, which can all be automated, so I would prefer to have to declare it in as few places as possible.
We are planning to implement CI/CD for our project. In summary, our setup is the following:
Code Repository (contains solution and project files)
Config Repository (contains .config files for different countries)
Aside from having multiple environments, we also have instances in multiple countries. Sample below:
Country 1
Dev
QA
Prod
Country 2
Dev
QA
Prod
I understand that Azure Release Pipelines can have multiple Stages (Dev, QA, Prod) and Variables that can be used for deployment. Then we can have a 1 Release Pipeline for each country.
What I am having difficulty is the Config Repository. Sometimes, developers may need to update a specific config file for a Country for a specific environment.
The only solution I can think of is trigger a release pipeline with this again, but just to replace the Web.config on IIS in the VM.
However, this is not good, because if developers only update Code Repository, any changes from Config Repository will be overwritten.
Any suggestions on how to automate multiple countries / environments with pipelines?
Thank you
Hi you can use Azure DevOps Environments to target environment strategy (in your case country and Dev/QA/Prod)
Normal practice shouldn't using repository for .config and any settings files.
you can also consider using Secure files for Azure Pipeline or inline script (within your environment deplyonce)
you can start exploring that Azure Pipeline Environment to understand it and YAML and how can it apply to you Multi-Stage YAML.
I have to configure the CI/CD pipelines for 2 web applications hosted in On-Premise environments & those web applications have multiple platforms (i.e. Dev, Test, QA & Prod). Both are .net applications. On-premise application source code was located on TFVC & recently have been migrated to Azure DevOps (Git).
Now, next step is to build the CI/CD pipelines for these applications. Also, other projects which are already on Azure DevOps, as per customer security standards, Agent pools are being used for build pipelines & Deployment pools/Deployment groups are used for release pipelines & hence we would need to go by the similar approach to build the CI/CD pipeline for 2 applications. Customer would like to use existing deployment pool to be used for rest 2 applications as well. Hence no need to build deployment pools so existing deployment pool could cater to multiple projects. How to achieve it?
Now, looking at the existing configuration of Agent Pools in Azure DevOps, we see that they are using Build Agent hosted in On-premise (TFS server itself) & is being used for building code for few projects.
Can same TFS server i.e. Build Agent could be used for other projects as well? Do we need to install Build agent again onto that server & run commands?
How about release pipeline? I assume, we need to build multiple stages for the release to happen.
Can someone explain step by step process please? I am not from development background & hence struggling a little bit.
You donot need to create new build agents or deployment pools for another projects in the same organization.
You can using the existing build agent pools and deployment pools in multiple projects by following below steps.
Go to project settings of the other project-->Agent pools under Pipelines-->Add Pool-->Existing-->Select an existing pool
Then the two projects can share the same build agents in the same agent pool.
Adding deployment pools to other project is simple too. See below:
In the portal of the other project-->Go the Deployment groups in Pipelines section-->go to Available pools tab-->Click the plus "+" to add the existing deployment pool to this project.
Then the release pipelines of both projects can target the same deployment pool.
Update:
If you cannot adding the existiong agent pool. You probably donot have the permission. You need to ask the administrator to add you as the reader. See below steps:
Go to the Organization Setting-->Agent pools under Pipelines-->Select the agent pool you want add to another project-->Go to Security Tab-->Add your account as Reader.
I am new to VSTS. I am deploying Azure services using PowerShell using VSTS Release management. Now, On dev environment, everything goes well. I want to deploy to Clients Production Subscription. Client won't allow access to Production subscription to the dev team. In that Case, I have Cloned Dev environment pipeline and named it to Prod.
I am using the config file for each environment.
The client doesn't want to check-in Config file of Prod environment. My Question is How to populate Config file in Prod pipeline? First I thought of to copy Config file directly in Drop Folder ( in VSTS agent VM) but if Developer also has access to a private agent then the config is still in Developers' hand. We can't use multiple agents somehow.
Is there any specific way or VSTS security where we set some access permission?
Is there any location where we can put the file and use it in VSTS?
If somebody doesn't understand question Please ask me I will explain in detail.
We have a similar situation where Developers are not allowed to access prod. To solve the problem, we've created a Dev and Prod project. Developers setup the production project initially, but are denied access entirely now using Azure DevOps security groups. Only our Ops group has access to prod, including the repo that the config files are stored in.
To get things from Dev to Prod, we have a third project for our build engineering team that has scripts to promote artifacts from Dev to Prod. This team is neither Dev nor Ops and the promotion pipelines that we use to promote artifacts require approvals.
Looks like all you need is to create a new git repo and add the file that you would like to use. After that, just add the git repo in any release where you want to use it by adding a new artifact, selecting the git option under "Source type", and selecting the name of your repo in the "Source (repository)" dropdown.
You can use Secure files to manage the config file.
How would one go about creating a secure means of deploying a package by way of Octopus Deploy?
Implementing a duplicate team, former for developers to deploy to development environment, the latter, to deploy to staging/production environment, with identical roles and specific users that would be team leads that can only deploy to staging/production.
The idea is to prevent developers from having to deploy or promote to staging/production as means of security.
It seems rather clunky in having a duplicate team, and would cause confusion especially when new octopus projects are created in the regards of syncing up between the duplicate teams.
What would you advise/recommend in this approach?
Ninja Edit I have included the tags teamcity and powershell as that is the idea - teamcity, when a build process is kicked off, that will deploy a build eventually leading to octopus deploy which will carry out the deployment process to that environment.
We're in a similar situation where developers are responsible for the DEVELOPMENT environment, testers for TEST and the operations team for PREPROD and PROD.
This is enforced by providing all users with access to Octopus Deploy, creating environment specific teams with roles scoped to particular environments; and assigning users to teams.
http://docs.octopusdeploy.com/display/OD/Managing+users+and+teams