We will be developing 3 asp.net web applications. Each of them will have it's own database. We don't want these applications to share resources because they're from different departments.
What is the recommended hardware setup that will allow us to have staging and production environments for each application?
I generally just have 6 boxes set up. 2 each for development, staging, and production...and then of course production can scale out from there. Then I use cruise control to push my code from one environment to the next. You don't need physically separate environments to run your 3 different applications.
Take a look at this for more information: SVN Website Development and Deployment Solution
Related
Looking at Microsoft documentation that says, under "Multiple deployment environments (production and staging)", that the "Service Fabric allows you to have multiple environments for your apps or to deploy different versions of your app side-by-side." How is this done and what does the topology look like? At any point in the cycle would different VMs in the cluster be at different versions or would different versions be installed on the same VMs? Particularly interested in Dev/Test/Prod environments, not simply upgrading Prod through a staging mechanism, though that would be good to better understand as well. Thanks.
I currently have a VS2015 solution that comprises of 6 applications, Web site, DB, Web Service, Console Apps.
This solution is deployed multiple times to different servers internally. At the moment i have only 5 working instances. Potentially i could end up with 10 - 20 50 etc.
I'm struggling to understand how Release Management could help me deploy this solution n number of times. Is there something else that i could perhaps use to orchestrate the deployment?
A release definition is a collection of environments. An environment is a logical entity that represents where you want to deploy a release. You can add environment in build definition to achieve multiple deployments.
More information, check https://msdn.microsoft.com/en-us/library/vs/alm/release/overview
I am developing an MVC 4 web application, VS2012.
For such applications I normally created an msi to install the app but for this project I am moving to the more modern publishing mechanism. I normally install to different environments:
dev
qa (server 1, 2, 3)
staging
prod (server 1, 2, 3)
Question is, do I need to create a publish profile for each of the environments, including a profile for each of the servers on qa and prod (as 1 web config setting varies between servers).
It seems like a need to create alot of publish profiles for this. Am I correct? What is the best way to manage publish profiles.
Publish profiles were designed for what you are describing. They allow you to specify different publishing configurations on a per server basis.
I am not sure what you mean by What is the best way to manage the publish profiles?. VS 2012.2 will manage these for you within the solution.
You can also right click on a publish profile and add a web config transform for that specific publish profile.
Sayed Hashimi has a good video explaining this here. http://www.youtube.com/watch?v=HdPK8mxpKEI
Where I work, we release bug fixes in to the system every night when we know our clients are not using the system.
Trying to take a step towards better service I'd like to deploy to IIS while the application is running.
A solution that comes to mind is to setup two different IIS applications and switch them over after deploy using a script. But I'm not going to try this out as I don't want any complications during our busy hours.
Does anyone have experience in this area of deployment?
Thanks
Regardless of whether you're using PHP, ASP, ASP.NET etc there is no native support for transactional deployment on IIS.
The simplest approach would be to have two physical folders and (optionally two web sites - one production, one test) on your web server, for example:
c:\websites\myapp\dep1
c:\websites\myapp\dep2
Initially your site would have its physical path pointing to c:\websites\myapp\dep1.
When you deploy your latest build you'd deploy into c:\websites\myapp\dep2. Once you're done just switch the physical path of the production site over to this folder. This means you still have the original site and can fall back to it if the new code fails for whatever reason.
The next time you do a deployment you'd deploy into c:\websites\myapp\dep1 and once you're done switch the production site to that folder.
You could optionally have a test site that points to the folder you're deploying to so you can make sure the site works before switching your production site over.
This could all be scripted.
Here's some related reading that may be of interest:
Publishing/uploading new DLL to IIS: website goes down whilst uploading
Is smooth deployment possible with componentized ASP.NET MVC apps?
Rob Conery also had an excellent blog post about the lack of a decent deployment story for ASP.NET application. You should take a trawl through the comments some of which are quite insightful:
ASP.NET Deployment Needs To Be Fixed
Getting Constructive On ASP.NET Deployment
I am setting up an automated deployment environment for a number of decoupled services that are in active development. While I am comfortable with the automated deployment/configuration management aspect, I am looking for strategies on how best to structure the deployment environment to make things a bit easier for developers. Some things to take into consideration:
Developers are generally building web applications, web services, and daemons -- all of which talk to one another over HTTP, sockets, etc.
The developers may not have all running on their locally machine, but still need to be able to quickly do end to end testing by pointing their machine at the environment
My biggest concern with continuous deployment is that we have a large team and I do not want to constantly be restarting services while developers working locally against those remote servers. On the flip side, delaying deployments to this development environment makes integration testing much more difficult.
Can you recommend a strategy that you have used in this situation in the past that was worked well?
Continuous integration doesn't have to mean continuous deployment. You can compile/unit test/etc the code "continuously" thoughout the day without deploying it and only deploy at night. This is often a good idea anyway - to deploy at night or on demand - since people may be integration testing during the day and wouldn't want the codebase to change out from under them.
Consider, how much of the software can developers test locally? If a lot, they shouldn't need the environment constantly. If not a lot, it would be good to set up mocks/stubs so much more can be tested on a local server. Then the deployed environment is only needed for true integration testing and doesn't need to be update constantly throughout the day.
I'd suggest setting up a CI server (Hudson?) and use this to control all deployments to both your QA and production servers. This forces you to automate all aspects of deployment and ensures that the are no ad-hoc restarts of the system by developers.
I'd further suggest that you consider publishing your build output to a repository manager like Nexus , Artifactory or 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, ControlTier can be used to further version control the configuration of your infrastructure.
I agree with Mark's suggestion in using Hudson for build automation. We have seem successful continuous deployment projects that use Nolio ASAP (http://www.noliosoft.com) to automatically deploy the application once the build is ready. As stated, chef, puppet and the like are good for middle-ware installations and configurations, but when you need to continuously release the new application versions, a platform such as Nolio ASAP, that is application centric, is better suited.
You should have the best IT operation folks create and approve the application release processes, and then provide an interface for the developers to run these processes on approved environments.