I have an general query about maintaining our project. Our project has some code changes between development source and production source. That is production source has live database configuration in web config, and payment checkout mode set to production in some class files. But in development source these are set to testing environment. Other than those both the development and production has same codes. Because of having difference between development and production source, we have to keep these source separately and work on two sources to publish any changes. We are frequently doing any features and bug fixes and publish the changes immediately. So we couldn’t follow Gitflow model (development and master). But Github model will suit for our case because of having immediate publish after feature or bug fixes done.
The problem is Github model says to maintain master source alone. But in our case master source connected to production database, so taking branch from master also connect to production. We need our development should be done with testing configuration. How can we maintain production and testing configuration in master branch itself and switching some configuration leads to connect to testing or production. What is the best way to do this?
Thanks,
Karthik.
From my understanding, Your problem really is about how to keep test config and production config seperate.
If I am right, then here is my two cents.
Say if all your config is in web.config, why not use the config transformation, where you save your test config to git (master) and
use transform to change it to production config when publishing.
In essense, it is just creating another Web.{build profile name}.config where when you publish in that build profile, your web.config will be transorm
more detail check
https://learn.microsoft.com/en-us/aspnet/web-forms/overview/deployment/visual-studio-web-deployment/web-config-transformations
For configuration changes use web config transformations. You can run those enable transformations on build with Visual Studio
Use dependency injection for mocking/faking implementations. You can set some key in web.config (the value is going to be set in web config transformations) which will determine whether to use fake implementation or the real-one
Related
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 have a console application where I need some ideas on how to build/release the config part of the application. When running locally in VS the config file is called app.config. After a build the file changes to .exe.config. We are using XDT transformation for building the config file to the different enviroment. But what would be the smartest way to ensure the naming convension is correct when release the build version to a server?
Seems you want to use TFS Build and deploy to multiple environments via Release Management.
For handling configuration in Release Management, there are two techniques generally used Config Per Environment and Tokenization.
If you prefer a clean separation between build and deploy. To achieve that, recommend tokenizing configuration.
More details please take a look at this wonderful blog: Config Per Environment vs Tokenization in Release Management
Environment specific application settings values configured in the app.config are tokenized. Above blog's method essentially inserts tokens into setting values during the build process. When deployed the tokens are replaced with matching Release definition configuration values.
Besides, for an example of a separate build and release solution, you could also take a look at this blog: Using web.config transforms and Release Manager – TFS 2017/Team Services edition (similar to app.config)
How is a test site created with Rails 4?
I'm building a Rails 4 app. I develop locally, have a github repo, and have a live production Heroku site.
Now I want a 'test' or 'dev' site that is on the web, so all the employees working with the app can see features even before they are rolled out.
It sounds like a standard enough issue that I suspect Rails has some built in approach, making use of the "dev", "test, and "production" environment variables.
Heroku has a methodology for this --
https://devcenter.heroku.com/articles/multiple-environments
I prefer to use standard git mechanics to control the flow. On a web application we develop this really helps us. We have a reasonable sized team and what we do is:
Create a feature branch (tools like git-flow can help with keeping standards in your team)
When done we push up to our git remote, create a pull request and someone reviews the contribution. Once the changes are good they get merged into master.
As part of continuous integration (after our specs are run successfully) we have a simple Jenkins job that clean rebases into the appropriate branch and pushes to the remote.
Everyone has their own flow, but you can use your master branch as development then when you're ready merge/rebase into your other environment branches.
On your destination Rails platform (in my case Ninefold, because it's really easy), pick the branch and deploy. On Ninefold as soon as you push to your branch your app is redeployed via a Post-receive hook.
We configure up the application's environment by passing RAILS_ENV=staging / RAILS_ENV=production, and ensure you have an appropriate (environment).rb file with all the relevant settings for your environment.
I'm trying to deploy my MVC4 app to ELB. The project has several post-build steps which pull together dependencies. The AWS SDK publish wizard then does not do the trick - it builds a Web Deploy package behind the scenes, which does not action those post-build steps or preserve the resulting directory structure.
So, I downloaded the command-line EB tools, got a git repository working, but can't work out the next step: what do I push to the server with git aws.push: because if it's just the resulting files then I can't specify the "Enable 32-bit applications" flag (required), etc. Do I then push a web deploy package from my repository?
I presume so, but if so, how do I include the files copied into the output folder during "normal" builds by my post-build steps?
Here we go. This seems to be in conflict with what Jim Flanagan was saying - below it's a zip file, but Jim says it's the contents of it.
#Jim Flanagan - perhaps you could comment if you have some time. Thanks.
Hi thanks for contacting AWS Premium Support
Communication from the Elastic Beanstalk Engineering Team.
When you aws.push an ASP.NET/MVC app you do not push the web deploy archive, rather you push the artifacts as you want them deployed on the machine. From the customers stack overflow question it seems they have already found the local git repo that the VS deployment wizard created and looking their should give them a good indication of what is needed in the git repository.
There isn't a nice way through the aws.push to specify what the "Enable 32-bit Application" app pool setting should be (or any other configuration setting). If you need a specific configuration setting set I would suggest creating the environment (via the console or using the eb command line tool) which allow you to specify the configuration. And then use git aws.push to deploy to that environment, git aws.push will just use the configuration that is already present on the environment.
The last question about still being incremental is not really valid since you are not pushing just one big zip file. But if you were, it could still be incremental depending on what changed in the zip file, it might just send a diff between the two versions of the zip file. As the question implies though that use case is not really what incremental deployments were designed to help with.
I have a team foundation server with build server, when I run a build it deploys to a website on that box. However I also want to do the same on Production which is a server on an external network and not part of the same domain.
I thought about looking at TFS Deployer but that just seemed to work within a network, I'm going to test it out as soon as I get a chance but I thought the best idea was to ask here when working with something so critical.
Is it a really bad idea to have a way of easily deploying to production?
Does anyone here deploy to production using whatever method? How do you do it?
Essentially the accepted answer will go to the person who can tell me the best method for achieving a deployment but pointing me in the right direction is sure to get an up vote as long as it's not too obvious.
Depending on the infrastructure you have available to you you can use wix to create msi's and use SMS configuration manager to deploy them to a target collection. This is the direction that we are moving to but have not reached yet. We also integrated wix into our build process to create the MSI artifacts. The reason we wanted to go down this path was because we are using CruiseControl.net as our continuous integration server and we have a nant script that we use to perform both the build process and the deployment process. They are both separate targets in the nant file, but what we wanted was a consistent model of deployment to all environments including production.
What are are doing currently is we are manually moving zips (which are artifacts of our current build process) to production. When the zips are unpackaged in the production environment we have to remove all the web.config, app.config etc from the zips and if we have new entries in the configs they are made manually.
Found msdeploy http://blogs.iis.net/msdeploy/archive/2008/01/22/welcome-to-the-web-deployment-team-blog.aspx