We need two extra columns / swimlanes in our pipeline, so that we can have 4 environments (dev / test / staging / production).
How is this configured?
You can't add new stages. Only development, staging and production are currently supported, and review if you are using GitHub.
Related
Is there a way to have multiple DDEV configurations for the same project? For example, we need to cover the case when we have several servers:
production with Apache + PHP 7.3 + Composer 1;
staging server with Apache + PHP 7.3, but a different. set of domains;
development with Nginx + PHP. 7.4 + Elasticsearch + Redis + Composer 2, where we're working on the system upgrade.
Dev team needs to emulate at least development and "stating" environments. Some features/hotfixes for production are under development and should be released before the big upgrade. This is a typical situation for (for example) Magento 2 projects with heavy customizations.
Is there a way to have multiple different environments like .ddev-prod, .ddev-dev etc., and somehow pass env name to ddev or configure it?
What comes to my mind is that we can create multiple configurations and add some information to Readme.md like:
"To start dev env: copy .ddev-dev to .ddev and run ddev start".
From your experience, what is the best way to maintain multiple environments?
Regards,
Max
The first thing I'd try would just be three different DDEV projects with different configuration (but the same code and database). That way you could easily see any differences. That would certainly solve the problem with mimicking the development server.
But it actually sounds like you need 3 branches of your code. Each branch could have different DDEV configuration and there you'd go. Use different project name for each.
Another approach would be to have a config.prod.yaml, config.staging.yaml and config.dev.yaml and copy just the one you want into the .ddev directory when you need it. But I think you'll be much happier with 3 branches of your code and 3 different project names.
So unfortunately we haven't upgraded from Azure Cloud Service to App Service yet. But I'm wondering how to automatically swap the Staging slot to Production slot with a Release Task.
The automated Release sequence is something like: 1) deploy to staging, 2) manual confirmation to swap staging to production slot, and 3) (after manual confirmation received) swap slots and delete staging instance.
Yes so the script from here works to swap Staging and Production slots:
https://gallery.technet.microsoft.com/scriptcenter/Swap-the-Deployments-f588a811
However, I had to set the Azure Powershell task to use an older version and classic resources.
Screen shots:
I am having 3 “Deploy a Release” steps in a Octopus project. I need to deploy each steps in a different Azure WebApp. How can achieve the this.
For example I have an octopus project named ‘Fruit’, and I have 3 steps in the project, each one to “Deploy a Release”
Step 1: Apple - To be deployed on an Azure Web-app ‘Alpha’ in Dev Environment.
Step 2: Orange - To be deployed on an Azure Web-app ‘Bravo’ in Dev Environment.
Step 3: Mango - To be deployed on an Azure Web-app ‘Charlie’ in Dev Environment.
All the azure web apps are under the same account. Kindly help.
Assuming that you will be having separate package feeds (alpha package,...) for each steps, you should be able to achieve deployment to each web app in same environment by using variables scoped to each specific step.
variable scoping
I'm looking at implementing a blue/green deployment strategy. It will be for a database driven web application. We are using Teamcity and Octopus deploy currently.
To my knowledge, to achieve this strategy, the changes to the database need to be such that both versions of applications will continue to work, so in the case the of a rollback, the database changes don't need to be reverted.
I have read Octopus suggested implementation of this here.
My question:
Does anyone test the current active application in prod against the database changes prior to promoting to prod? E.g. In Test or UAT?
If so, how do you fit this requirement with the deployment strategy, especially when configuring it with Octopus?
Does anyone test the current active application in prod against database changes prior to promoting to prod.
Octopus lets you easily deploy the current live version to your pre-production environment, so you can test it against the upgraded database prior to deploying the upgraded database to your live server.
So if you have version 1 of your application live with database version a, and have version b of your database coming through, followed by version 2 of your application, you can test this in pre-production...
1 a - Same as live
1 b - First phase of testing (followed by release of `b`)
2 b - Second phase of testing (followed by release of `2`)
How can I host concurrent environments of a single application of on AppHarbor?
We are currently in development so a single environment of DEBUG is sufficient, with builds triggered from the develop branch.
Soon we will need a PROD environment, triggered by changes to the master branch (or perhaps manually).
How can I configure AppHarbor such that both the DEBUG & PROD environments are accessible at any given time for a single application?
With hostnames such as:
http://debug-myapp.apphb.com
http://prod-myapp.apphb.com
For now you will have to create two applications, one for your debug environment and one for your production environment. You can also set up the tracking branch for each application. Here is a link where we describe how to manage environments.