Can we maintain different configs under single installation of flyway ? Means if i want to install flyway on central server and perform deployment for multiple services ?
It is possible to maintain different configurations for e.g. dev/test/prod of the same application or different applications under the same installation.
install flyway on central server and perform deployment for multiple services
This is the defacto approach for continuous delivery pipelines.
Achieve this by having application/ environment specific configuration files and use the -configFiles option.
Refer the doc: https://flywaydb.org/documentation/commandline/#config-files
Related
We have a ASP.Net solution which has multiple projects and 4 different build configurations (debug, Test, Preprod, prod). There is no build configuration check in the code and hence the only difference between the different configurations is basically the configuration (in web.config).
What would be an ideal Jenkins job setup, so that the job spews different folders for each configuration with same bin and repective configuration.
We have done exactly same deployment for our asp.net webform solution for different configuration. To acheive that you will need to do follow few steps.
Create seperate publish profile in your project for each configuration(DeveloperProfile,TestProfile,LivePublish), so while you setup job in jenkins you can refer each for respective job. for ex. Under Properties>Publish Profiles
Now in jenkins when you setup job, refer respective publish profile and settings for each environment and you will be able to acheive your goal. For ex. i am giving you picture of our test environment job configuration in jenkins which does A). Pull source code from source control before publish B). Update nuget packages before publish C). Compile and Publish Website.
You can use web.config transform for the config transformation for various environments. Then you can try using Jenkins plugin for TFS and perform multi-server deployments easily using TFS CI and CD.
I am deploying a Spring Boot application to AWS Elastic Beanstalk using AWSCLI. I want to put an external application.properties file containing customer specification configurations (database credentials, etc.) in the same directory of the application. The application should pick up this properties file. How can I accomplish that? Are there any alternatives?
Spring Cloud Config
This project allows you to use an external, centralized configuration repository for one or more applications. You don't need to rebuild your application if a property changes. You can simply change the property in your configuration repository and even push the changes to all of your applications.
See this Getting Started Guide.
This above approach is what I would recommend for the scenario you described. I would not bother with having a separate directory on the application server for your configuration files. Spring Cloud Config is a great approach as it solves the problem you described and a few more.
You can alternatively specify them in an application-prod property like
server.port=5000
spring.datasource.url=jdbc:mysql://${RDS_HOSTNAME}:${RDS_PORT}/${RDS_DB_NAME}
spring.datasource.username=${RDS_USERNAME}
spring.datasource.password=${RDS_PASSWORD}
spring.jpa.hibernate.ddl-auto=create
and specify an environment variable called SPRING_PROFILES_ACTIVE with the value prod making the beanstalk smart enough to pick values from out there.
What is the best practice of configuration management for web applications that are published to Amazon Beanstalk?
Now configuration of our web application is separated among several files. One of them is web.config, where we have basic connection strings.
Others are custom xml files with configuration of different application modules. These files are mapped to config classes via default xml serialization.
The simplest way is to add these configs into Visual Studio's project. But this solution produces several questions:
We do not want our production settings be visible to newcome team members.
We want to be able to switch between different configurations of application - we have our local server with SQL Server, which is used for development as it is faster and more responsive than Amazon's instances we use.
We can consider moving all application and its modules settings into System.Configuration format and use config file transformations, having two solution build configurations - one for Amazon and one for dev environment. But this means we would have not to forget to switch to Amazon solution configuration before publishing project. Is it possible to set solution configuration that will be used to publish to Amazon by default?
Can anyone provide insights of using Jenkins for automating deployment under controlled and uncontrolled enviroments. We have different environments - dev/qa/uat/prod and currently we are using batch files that call msbuild/nant scripts to deploy on web and DB servers (web farm). Developers only have access to dev/qa and production support will deploy on uat/prod. Prod. support will get the source code from SVN tag folder and run the batch file to deploy the application.
By using Jenkins, is it possible to eliminate the step of prod. support team getting the script from SVN by running the jobs using their credentials via url. And what is the general practice using source control and CI tool for deploying applications.
My recommendation is to reserve Jenkins for just building the software. That way the user of Jenkins only have access to development and perhaps QA systems.
To decouple the build system from the process that deploys the software I recommend the use of a binary repository manager like:
Nexus
Artifactory
Archiva
In that way deployment scripts could retrieve any version of a previous build. The use of a repository manager would enable your QA team to certify a release prior to it's deployment onto production.
Finally, consider one of the emerging deployment automation tools. Tools like Chef, Puppet, Rundeck can be used to further version control the configuration of your infrastructure.
Does Microsoft offer a tool where you can deploy a web application to multiple web servers in a load-balanced environment/web farm?
My team is looking for a tool, preferably from Microsoft, where we can deploy our web application from development environment to production environment automatically.
If I understanding what your asking for your looking for a build server, to my knowledge Microsoft don't offer one, but some to take a look at are Team City, Hudson(requires a plug-in), and CruiseControl.net.
Basically they work by pulling from your source control building your application and running your tests. They all support scripting that will allow you to build then deploy to your servers. This can be set up to run nightly, weekly, etc. you can also set it up to monitor your source control for changes and build anytime it sees a change
The only one I've used is Team City, the install was easy, and depending on how many build agents you need it's free.
If your just looking to build and deploy from VS Another option is creating an NAnt script and running it from VS as an external tool.
For a good over view of Build servers check out this SOF question cruisecontrol.net vs teamcity for continuous integration
The Web Deployment Team blog at Microsoft has some reasonably useful information, and have a deployment tool you could try...
In the last environment we setup we used TeamCity for all our builds and deployments (Which is basically to say we wrote MSBuild scripts and automated them with TeamCity). In short we had the following 5 build configurations:
Continuous Build - Automatically rebuilt our product upon every check-in. Running all the tests. This build did not deploy anywhere
Nightly Build (Dev) - Automatically build and deployed our product to the development web server (no server farm). We build would run the tests, update the development database, shutdown the Dev IIS web site, copy the necessary files to our web server, and restart the site
Test Build - Like our Nightly build only it deployed to our test environment and it wasn't scheduled so it had to be manually started by logging into Team City and pressing a button
Stage Build - Like test only deployed to a web server that was externally visible to our customers sot that they could validate the application. Also, only run on demand.
Production - Created a zip file of our product that the deployment team could install on our production web servers
So I guess what I'm suggesting is that you use TeamCity and then write build scripts in such a way that they'll deploy to your Web Farm. If you want examples I could supply you with the pertinent portions of our build scripts
** One more thing: we check in our web.config files and such for each environment into subversion and then part of the build process is to copy and rename the appropriate config file for the environment. For example, web.prod.config => web.config in our production build
I believe that Sharepoint does this.
File Replication Service ( e.g. DFS Replication ) is a typical and very good choice for doing this.
Your changes are synced between member servers at the file system level.
Sharepoint does this automatically when you deploy a solution package.