forgive me i'm new to capistrano
we have multiple sites we want to deploy with capistrano. Each site is deployed to the same set of servers. Instead of adding the same set of servers to each capfile for each site how would we have 1 file to holds roles and tell each site capfile to use the global roles file?
You can use Multistage extension
https://github.com/capistrano/capistrano/wiki/2.x-Multistage-Extension
Related
I have a microservice application in one repo that communicates with another service that's managed by another repo.
This is not an issue when deploying to cloud, however, when devving locally the other service needs to be deployed too.
I've read this documentation: https://skaffold.dev/docs/design/config/#remote-config-dependency and this seems like a clean solution, but I only want it to depend on the git skaffold config if deploying locally (i.e. current context is "minikube").
Is there a way to do this?
Profiles can be automatically activated based on criteria such as environment variables, kube-context names, and the Skaffold command being run.
Profiles are processed after resolving the config dependencies though. But you could have your remote config include a profile that is contingent on a kubeContext: minikube.
Another alternative is to have several skaffold.yamls: one for prod, one for dev.
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.
I have a SFC that getting deployed to different staging environments. The services have some settings parameters on the settings files. The values of these settings change depending on the staging variables.
I've read this article Manage application parameters for multiple environments but there is not clear what with is meant with Environment. Is it number and type of nodes or the staging env.
How I can change those values from a Release/Build definition? Is there ApplicationParameters transformation just like in Web.config?
Thanks
In service fabric, your Application will have one ApplicationParameter file per environment, and also, one PublishProfile.
Your publish profile will define some deployment configurations, one of these configurations is the ApplicationParameter file.
I'll assume you are using VSTS to deploy your cluster.
You will add a service fabric deployment step, it will require a few settings, one of these is the publish profile path.
To make it dynamic, I'd recommend you to name your PublishProfile the same way you name your environments, and use the environment name to get the publish profile.
Summary:
VSTS Release will run the Service Fabric Deployment Step.
SF Dep. Step will use the environment name to find the publish profile(Example: Environment=Prod -> PublishProfile=Prod.xml)
PublishProfile will point to an application parameter file
The application parameter file will have the settings applicable to that environment(I recommend to use the same naming pattern here Prod.xml, to ease maintenance)
With this configuration, you can use the same release definition to deploy the application into multiple environments, if a new environment is created, the only thing you have to define is the PublishProfile and ApplicationParamenter files.
My team uses local capistrano scripts for deployment of a few web apps. We use beanstalk's hosted repository for our git repos.
It's always bothered me that our deployment workflow doesn't give us a centralized log of all deployments to each environment. Beanstalk's deployment feature seems to accomplish this goal and much more.
Some weird legacy requirements meant that beanstalk's simple FTP deployments were insufficient. However, their deployment feature can now execute SSH commands and their deployment case study made me seriously reconsider our workflow.
What are the downsides of the beanstalk approach relative to the local capistrano one? Is there any reason I shouldn't make the switch?
The best thing about SSH deployments in Beanstalk is that you don't have to decide between Capistrano and Beanstalk. One of the best use cases is to use them together: Beanstalk as a manager and Capistrano as a performer.
You can setup SSH deployments in Beanstalk to login to one of your servers and issue a Capistrano deployment from there. It will then deploy code to itself and other servers.
This way you get flexibility and bullet-proofness of Capistrano (transactional deploys), with the easy-of-use, permissions, notifications and timeline of Beanstalk Deployments.
This also gives you an ability to run Capistrano deployments from a mobile device or a computer where there's no Capistrano installed.
P.S. — I work at Wildbit.
What is the proper way to set up Capistrano to deploy a Rails app to multiple environments with different permissions required for each environment? In other words, imagine a typical scenario where a developer makes changes to code and pushes the changes to a testing environment. After testing, a release manager pushes the changes to production. And so on, with possible additional levels in between. Capistrano (even with the multistage extension in capistrano-ext) seems to be built for a single user having permissions to deploy to any environment. What is the recommended setup for cases where people at the bottom level shouldn't be able to deploy all the way to production?
In setting up Capistrano and deployment, there are differences between the user account which is used for deployment and the people with permissions who can deploy.
In Capistrano you setup the user
set :user, 'deploy'
This user account must exist on each machine the Capistrano deploy script connects, each role app, web, db. It is recommend to set it up with SSH key authentication.
When someone uses the cap deploy it will connect to the machines with SSH-Keys and will work only if you have your public key installed on that account.
This method allows different people to have different access to the machines. For production, only install the SSH-Keys of the people with admin access to the machines. Then even if someone runs the cap deploy it will not work since they cannot connect to the remote user.
We allow anyone to have their SSH key on the staging environment, but only a couple of people have access to the production server.