How is the worklightserverhost attribute on the app-builder task used? This is important as when deploying an tested application into a production environment, you normally wouldn't do a new build (as this could introduce regression problems). However, the fact that this is a mandatory property and contains in this scenario the test server URL and context - does it force you then to do a new build for the production environment?
Yes, a re-build for each environment does seem to be the usual approach. While we might prefer a "build once, promote through the stages" pattern, I think by careful use of tagging in your source repository you can get pretty good defence against regression.
Alternatively, I think with care you could set up your network so that the app is built once directing to, say,
myco.mobile.hostv21
you could then have that resolve to the different stages as appropriate.
Related
Setup:
Private master repo and every developer has their own private fork.
Currently using CircleCI, but we'd be happy to switch to satisfy requirements
Branches on master repo are protected with merge restrictions
Requirements:
Build + test on forked pull requests
Deploy to different environments based on master repo branch updates
Not all developers can be fully trusted with production credentials
Partial Solution:
Enable building and passing secrets on forked pull requests (Reference)
Use CircleCI contexts to set environment variables per branch. This allows different deploy targets.
Problems:
All repo specific secrets as well as all global contexts are now accessible by anyone who can open a PR.
Even if we disable building on forked pull requests, anyone with write access to at least one repo can access all global contexts.
Question:
This would seems to be a very common use case. How do other companies solve it?
Is CircleCI not the right tool for this? - No, it is not (see below).
Should we build a custom solution?
Edit1:
CircleCI got back to me and surprisingly this is not a use case they support. Looking into other providers now. Above questions are still unanswered.
Edit2:
I've also contacted TravisCi and SemaphoreCi and it appears that only TravisCi supports building forked PRs and not leaking secrets into them (Reference).
SempahoreCi is missing (1) building forked PRs and (2) hiding secrets from the deployment phase in non-master workflows
CircleCi has restricted contexts, but they would require manually changing workflows. Definitely not easy to set up and I don't fully understand how they would work.
First of all, sorry if this thread is not appropiated in Stack Overflow, but I think that is the best place of all.
We are using Rancher to manage a microservices solution. Most of the containers are NodeJS + Express apps, but there are others like Mongo or Identity Server.
We use many environment variables like endpoints or environment constants and, when we upgrade some of the containers individually, we forget to include them (most of the times, the person who deploys an upgrade is not the person who made the new version).
So, we're looking a way to manage them. We know that using a Dockerfile could be the best way, but if we need to upgrade just one container, we think that is too many work for just a minor change.
TLDR; How do you manage your enviromental variables in Rancher? How do you document them or how you extract them automatically?
Thanks!
Applications in Rancher are generally managed using Stacks/Services. Dockerfile is used to build a container image. docker-compose/rancher-compose files are used to define the applications. The environment variables can be specified in docker-compose file.
When you upgrade a service in rancher, the environment variables information is carried forward and also it's possible to edit them before upgrade.
Also Rancher "Catalog" feature might be something useful for you. Checkout: https://rancher.com/docs/rancher/v1.6/en/catalog/
Currently I am using ms-deploy to build and deploy on several machines using team-city. In my current scenario, I need to build, package and deploy on Dev. After this I need to deploy this package on test and Live servers (which are on different domain. I understand how we do it but problem is Web transformation only occurs for test and live configs if we build a package. It means if I want to use the same package that is created for Dev cannot be used, as web transformation only occurred for Dev web config. Also know that we can change web config when un-packaging but that parameters are very limited. We have a lot of changes not just the connection string or db changes.
Another solution is to add another step to build packages for test and live as part of Dev deployment but then it means a lot of copying on remote servers, once for test and once for live which is a lot of time consuming due to different domains.
Can you please guide what is the best solution in this scenario. So I can use team-city to publish to Dev and test and live using same package and different web configs in one go.
To configure items at deployment time which are not automatically created for you. You can add a file named parameters.xml to your project and extend what you want to make available at deployment time.
Here's some documentation on the approach Using Deployment Parameters for Web.Config File Settings.
I have two Rails 3 applications that will share portions of the same database through an internally developed gem. This is an internal project where we will always have full control over both applications. One application is bare metal administration (dev facing, potentially unstable) and another is the content publishing system (user facing, production). Its not practical nor desirable to meld the applications.
I've already seen Rails - Shared Database Tables between two apps
My proposed solution is to git submodule and share the /db directory of both applications.
I want to know if this is a valid approach, and if so are there any pitfalls I'm setting myself up for? If this isn't valid what is a good alternative? (The goal here is to remain as simple as possible, no interprocess APIs.)
I have used this approach and it does work. If you are using capistrano for deployment enable submodule deployment like this
set :git_enable_submodules, 1
You have to be careful not to forget to sync the /db folder, before you start creating migrations, they are created with a timestamp and you can end up with the wrong sequence of migrations.
My Active Resource connects to some stupid external service that takes a while to respond for whatever reason. This is a little too nagging. I would like to stub Active Resource during development to speed up my development time.
Is this a good thing to do? I think it is. If you think otherwise, please explain.
And is there a mechanism to stub it out based on a switch in environment configuration file, possibly any gem/plugin that you have used for this purpose?
What and how do you do all these in your experience?
I recommend using FakeWeb. I used this on a project recently and it allowed me to register a number of external urls with a predefined response. In your test setup you could do:
FakeWeb.register_uri(:get, %r|users.xml|, :body => File.read("spec/factories/xml/users.xml"))
Now whenever active resource requests anyhost.com/users.xml (in test environment), you'll instead immediately get the contents of the file your referred to. I like this approach because when you're testing a model, you don't really want to be testing the external service too. I'd leave that level of testing to an integration test.
This won't affect development or production environments, so you can use your stupid external service as usual.