I have release build that has been kicked off already, this build was kicked-off it went through QA and staging environment successfully, the users were happy with the app on both these environments. I then added the last environment that is production. Now my question is, is there a way of getting the current build to see that there is an extra environment added, at the moment it looks like the production deployment does not exist yet I know its there, here is the screenshot of the prod environment that was added
The below screen illustrate that the app deployed succcessfully to the other environments but the prod environment does not appear, the area highlighted in red is where I am expecting my prod environment to appear
I understand queuing or kicking off a new build would make the prod environment appear but I wonder if is there a way to let the current release that there is new environment added.
No. The pipeline is locked in when the release is created. You can create a new release using the same build that you'd previously deployed to lower environments. That will pick up the production environment that you added to the release definition.
I don't think already running releases will have PROD environment aded
Related
I have a react native application built and distributed through microsoft appcenter. for the iOS side, I have a release variant which is the live production variant. and i have a staging variant. the git flow im trying to achieve is something like this:
create feature branch from either master or staging (for the sake of
this argument) -->
push OTA update to staging variant -->
merge staging variant into master (this is the key part)
I want to be able to merge staging into master without having to manually set the defaultConfigurationName each time i pull staging into master, or push the master-branched-feature-branch to staging. I want a dynamic value: master's value to always be 'release' and staging to always be 'staging'.
Problem:
When merging staging branch into master branch (production), the defaultConfigurationName in project.pbxproj changes the variant that will be built by microsoft appcenter from the release variant (production) to the staging variant
lets say i have an env variable called "ENVIRONMENT", with values of 'release' and 'staging', corresponding to 'master' and 'staging branches. i want to automate management of the ios build configuration when merging staging into master, and not have to manually reset defaultConfigurationName back to 'release' each time i merge staging into master. how can i set the env variable's value to the value of "defaultConfigurationName" in project.pbxproj file?
Note: i dont need help setting up environments or environment variables. i also dont want to create an additional target.
I came across this issue and found that you can update the info.plist file found in ios/app/app/info.plist to include your environment variables.
Eg
<key>CFBundleVersion</key>
<string>$(CAPACITOR_BUILD_NUMBER)</string>
Please have a look at this blog post, it shows how to set up multiple environments for android and iOS.
Should I replicate the production environment (docker image, dependencies, etc) when running tests?
The question is because how do I get composer development packages like phpunit and phpstan if I am replicating the prod environment?
What are best practices regarding this?
Should I replicate the production environment (docker image,
dependencies, etc) when running tests?
The immediate answer to this is yes. By replicating the production environment in your test environment means that you can limit issues that only happen in one specific environment biting you in production.
Having said this there are many times where it is not appropriate to make your test environment identical to your production environment. E.g. for a web service you cannot (easily) in CI run your tests against the production domain name.
Docker makes it a lot easier for you to use the production environment in other parts of the SDLC e.g. development and CI. I would advise making the docker image for your production environment available to all working on the project (dev, QA etc.) There will be examples where people want to move away from the production docker image, for example, installing additional debugging tools that should not be available in production.
In summary, using your production docker image (and dependencies) in your test / dev environment will give you greater confidence of how your product will perform in production. This will reduce your time to market and environmental issues in production.
What does it mean by deploying code from dev to prod environments using Jenkins. Can anyone please help. I currently have the source code in my gitlab. I need to deploy this code from dev env to prod env
Thanks in advance.
Source code present in GitLab is just the files that is needed to create a WAR/EAR/JAR to run the application.
It's the environment files if present which makes the application behave slightly different on each environment i.e. DEV/PROD the data that you see on DEV will not be the same that you see on PROD(application is live), as developers tend to test/modify code/data to ensure that the application works as excepted. This is fine on DEV but is a big no-no on PROD as it will impact business.
Deploying code from dev to prod environments just means building the application with the right environment files e.g DEV points to xyz DB but prod points to abc DB.
All this can be achieved with jenkins and if your project uses maven/gradle then with a single line command you can achieve the above.(A bit of googling will help you here)
If your project doesn't involve Maven/Gradle then you will have to replace the environment file each time a build happens based on a parameter which can be passed from jenkins.
This whole process is part of DevOps culture. In simple terms it looks like this:
Developer pushes changes to source control (i.e. gitlab).
Build server (i.e. Jenkins) automatically downloads latest changes and builds an application (i.e. creates setup files or just the binaries). Usually you run tests (unit, integration, automation tests etc.). If something fails then developers get notified about it. This whole process is called continuous integration.
If everything went right then you can deploy your application to production. This part of the process is called continuous deployment.
It's a common strategy for web apps. For larger projects QA team tests the software and the software gets deployed once QA team approves it.
I am using TFS on-premise, but this question pertains to the team services release management online too.
I am working on a new setup to use the new Release Management tools. I have a Main line in TFS source control, branched into a Dev branch. All work is done and checked in on the Dev branch. We manually merge code from the Dev branch back to the Main branch. When we do this, we have a auto build in TFS to download the Main branch repository and do a build of the source. I have a release management environment setup to take this build of the Main and deploy it to a staging environment, and then to take the same bits and deploy to a production environment.
My question pertains to the process of releases and bug fixes. Normally we would use a release branch per release, and then apply bug fixes to that code and release from that branch. I don't know the best practices for handling this situation in Release Management. I still want to use the RM configuration I have setup to perform the release of these bug fixes, because I need to put the bits through the same QA process and have auditing/records, and also use it to deploy the bug fix release to staging/production.
I can't find any guidance on MS documentation about how to best do this through Release Management.
You could create a new release definition to deploy application to production environment. For pervious release definition, it is used to deploy application to staging environment to do test and verify.
So, if bugs be fixed, check into Dev branch and merge into Main branch to trigger build and release (deploy to staging environment), after a major release is ok and approved, trigger another release manually to deploy to production environment.
I'm trying to test some changes out on production without having to commit and push the changes because I only want to commit what actually works. The project I'm working on was created with Rails (3.0.2), and deploys with Capistrano (3.1). I've tried making changes in the root folder of my app and redeploying, and the changes are not reflected on the website. I've tried making changes in the root/current directory and redeploying and that didn't work.
Is there any way I can redeploy changes to the server without having to push it to Github first?
Is there any way I can redeploy changes to the server without having
to push it to Github first?
No this isn't possible since one of the first things that Capistrano will do is git clone the latest from whatever branch you've specified in your deploy config.
I'm not sure what your familiarity with Rails is but the proper way to do this would be to create a new staging environment and deploy to that. The staging environment would have similar settings to your production environment with a separate database so that you don't affect production data.
Capistrano 3 supports this flow out of the box so that once you've set everything up you can simply call
cap staging deploy
to deploy to the staging environment, and
cap production deploy
to deploy to the production environment.