Packaging ASP.Net Application for Elastic Beanstalk Using Jenkins - asp.net

I've set up my Jenkins server, and am able to build my solution (with multiple deploy-able projects in it) properly. Now, I'm trying to get everything in a project ready to deploy on Elastic Beanstalk, but it seems like I'm missing something such that when it gets "deployed", it is deployed such that my old code is still running.
I've tried searching around for anything to tell me how the AWS Toolkit plugin works, but haven't found a good breakdown on what it does when deploying. If anyone has an idea on all the steps it takes, I'd love to hear it. It seems like it's using MSDeploy in some way before zipping, but I don't know how to replicate the plugin's results using the command line.
Credentials are fine and all, I can go into the console and see that it's "updating" the instances, which is why I believe my problems are in my packaging.
Plugins being used:
MSBuild - http://wiki.jenkins-ci.org/display/JENKINS/MSBuild+Plugin
AWS Elastic Beanstalk - https://wiki.jenkins-ci.org/display/JENKINS/AWSEB+Deployment+Plugin
Configurations:
MSBuild file - SOLUTION_FILE
MSBuild Command Line Arguments - /property:Configuration=AWS-Staging /property:Platform="Any CPU" /clp:ErrorsOnly
AWS EB Packaging Root Directory - PROJECT_DIRECTORY\bin

Found the solution - Add /t:Package to my MSBuild parameters

Related

Prevent appspec from running scripts (disable hooks)

I'm new to codedeploy. I managed to make a deployment to an ec2 instance successfully (and using git to manage code so everything works beautifully now).
I want some other people besides myself working in the project to be able to deploy source code to the instance but not be able to run a script (especially because codedeploy seems to be running as root). Think of it as an admin/webmaster scenario.
In other words, appspec.yml has the "hooks" section under it and you can run any scripts as part of the deployment. I want to prevent this, the instance has all the software ready for the deployment so won't be needing this.
2 questions:
1) Does this make sense or am I grossly misunderstanding something/am I overkilling by using codedeploy altogether?
2) If it makes sense, how can I achieve this?
This doesn't seem to be something that CodeDeploy is able to do at this moment. But do you want to disable the auto deploy from Github to CodeDeploy? And if anyone else push a code change, it'll exist on Github. When you are ok with the changes, you can do a manually deployment from Github on CodeDeploy console.

Can't deploy to Elastic Beanstalk: ERROR_FILE_IN_USE

My Elastic Beanstalk installation won't deploy through Visual Studio due to this error:
2016-07-01 20:45:02,627 ERROR 1 AWSBeanstalkCfnDeploy.DeploymentUtils - Exception during deployment.
Microsoft.Web.Deployment.DeploymentDetailedClientServerException: Web Deploy cannot modify the file 'msvcr100.dll' on the destination because it is locked by an external process. In order to allow the publish operation to succeed, you may need to either restart your application to release the lock, or use the AppOffline rule handler for .Net applications on your next publish attempt. Learn more at: http://go.microsoft.com/fwlink/?LinkId=221672#ERROR_FILE_IN_USE.
The link suggests that I create a pubxml file with settings to enable AppOffline, but this file only seems to be relevant for publishing through VS using the built-in Publish feature. I haven't found any documentation suggesting that this will work for AWS.
How do I enable AppOffline for an Elastic Beanstalk deployment?
Thanks!
Sorry that this is only general advice and not the code you need, but the solution is to use hooks via .ebextensions. Please see http://docs.aws.amazon.com/codedeploy/latest/userguide/app-spec-ref-hooks.html.
You can add the execution of a powershell script to add app_offline.htm before the update is extracted and remove it once the update is deployed.
We had a similar issue, but the DLL in question (abcPDF, v9) was only blocked because we were initializing the licensing of it during application_start(), which EB did not like. So we moved applying the license elsewhere.
However, I think this approach would work.
--
Oh, maybe this container command will work for you. It recycles the IIS app pool right before the It didn't for us because of the aforementioned licensing locking the DLL.
/.ebextensions/recycleapppool.config
container_commands:
__recycle_app_pool:
____command: c:\windows\system32\inetsrv\appcmd.exe recycle apppool DefaultAppPool
After quite a lot of experimentation, the only working solution I could find for this problem was
// in Project/.ebextensions/reset.config
container_commands:
00_nuke:
command: IISReset
waitAfterCompletion: 0
The cost was about 4 seconds of downtime (on a t2.micro), during which you get a 503, which certainly isn't great.
Note there's a Github issue for this (open at the time of writing).
If you have the option, deploy your service to Azure rather than AWS and there are configuration options to work around the issue (such as an environment variable MSDEPLOY_RENAME_LOCKED_FILES) - related Azure specific question.

TeamCity for static site

I am a front-end developer. I do a lot of PHPs/CSS/JS and HTMLs. Currently, how we do our deployment to staging environment is to push our codes to GIT servers. Go to our staging servers and do a pull to some directory. And then manually move the files from the directory to the correct directories in our apache web server.
Will it be overkill if I use TeamCity to do this? I intend to write an ANT script that does the copying which means to say Runner type will be ANT. So every time there is a push to the GIT repo, Teamcity will pull and then run the ANT script to copy the affected codes to the correct directories.
If not, I will gladly love to listen to any suggestions.
Thanks
Teamcity may be overkill right now, as you would just be using it as a fancy trigger for your build.
But consider adding custom build parameters, which it can pass to your script. You can then start automating builds to different environments through a friendly UI.
You then have a platform to base a correct deployment process around further down the road.
Come the time when you need PHP compilation, JS minifcation, unit testing, its all just another step in your TC configuration.
I would recommend it.

Deploy a website from Visual Studio to webserver

I'm using a blank VS2010 solution to manage a static website I maintain. I was going to use the ASP.NET website project, but that added a bunch of stuff the webserver wouldn't do. If I should still use that project, please let me know!
I have the code under source control and try to have the DEV region in source mirror the DEV webserver. I want to migrate my changes to the dev server for others to view, but I'm not sure of the best method to do this. If I use the Publish Website command in VS, it will delete the files on the server and copy all the files. The problem with this is that it takes waaayyy too long. Especially when I am on the VPN. I could manually copy the files, but that's a sloppy way to do it. And the server doesn't have FTP so that's not an option either. Is there some blatant method I am missing?
I thought about setting up a workspace with the server as the working folder. Then, whenever I wanted to migrate a change, I'd just do a "get latest" in that workspace and it would bring down any files that have changed. Does this sound like an okay method or is there a preferred method for this?
Have you tried the copy/website functionality
First of all, I recommend against using web site "projects" for anything. Use a Web Application Project instead.
Secondly, when you use MSDEPLOY from the Publish command, it synchronizes the target web site with the source - it will only deploy changed content.
Set up a continuous integration server (ex. CruiseControl.NET).
Create a new build project for each website you wish to deploy, initially configured for manual invocation.
Configure the build project to do a get latest and deploy.
Here are some possible implementations:
http://callicode.com/Homeltpagegt/tabid/38/EntryId/27/How-to-only-publish-the-runtime-files-of-an-asp-net-application-using-CruiseControl-net.aspx
http://confluence.public.thoughtworks.org/display/CCNET/Build+Publisher

A build and deployment machine with a web-based dashboard

Here is what I am trying to do: I have my code sitting on Bitbucket (it is a ASP.net web application). I want to put together a build machine that has a web-based dashboard. I go to the dashboard and I say: Ok show me all the branches and stuff on my Bitbucket project. Now please get the latest code from this branch for me and build it. Then please deploy it to this location for me or maybe this other location. I want this dashboard give me a history of all this builds and deployments too. I am very new to this concept I have been reading about CC.net and MSBuild and other stuff but I can not find the right answer. Please put me in the right direction.
The point of a build server is that it automatically runs a build each time you commit something to your repository.
In order for the build server to know exactly what to do, you normally put a build script (with MSBuild or NAnt) into your solution which does everything you want - building your solution, maybe create a setup package and so on.
The build server basically knows where the repository is and where in the repository your build script is.
You need to configure this once in the build server, and then it will always run after you commit (but you can also start a build manually, if you want).
If you want a solution with web-based dashboard, try TeamCity.
It's a commercial product, but it's free for up to 20 users.
You can do everything in the web interface - configuration, running the builds AND browsing the build history.
EDIT:
Houda, concerning your question about deployment:
I don't think that TeamCity has a "deployment mode" in that sense. What you could do is include the deployment stuff in your build script that is run by TeamCity.
So, after the build itself is finished, copy the generated assemblies and files on your web server(s).
If you do it this way, you HAVE to make sure in the build script that the deployment will only happen if the build didn't fail (and if you have unit tests, if the unit tests didn't fail as well).
This is very important for a live application, because if you don't take care of this well enough, your app will go immediately offline every time someone commits "bad" code to your repository (and it will stay offline until the next "good" commit)!!
EDIT 2:
See Lasse V. Karlsen's comment below: it's more comfortable with the new TeamCity version 6.

Resources