If you have a SSDT Database project in VS 2015 set as the startup project, it performs both a build and deploy when you hit F5
========== Build: 1 succeeded or up-to-date, 0 failed, 0 skipped ==========
========== Deploy: 1 succeeded, 0 failed, 0 skipped ==========
This is different than "Publish..." command, because it does not take you through the publish dialog. It just automatically deploys to the localdb instance(pointed to via the project's Debug config.
I often need to deploy the database to localdb so that I can run code generation tools against it, rather than running the entire solution(that has other applications, i.e. I would not want to run via F5).
So what I want to do is determine if there is a project level commend that I can add to my toolbar that does this automatic no-dialog deploy to localdb, other than F5's Start Debug command. I am looking through the Add Command dialog(right click toolbar->Customize), and also looked through the SSDT.* commands from the Keyboard customize in options.
Does anyone know if there is a command just for a Database project Build+Deploy or Deploy, that does it automatically? (Again the "Publish..." command is not what I'm looking for because it doesn't automatically deploy as above)
I have played around with different ways to do this, my two approaches I sway between are:
Have a powershell script to call sqlpackage.exe to deploy the dacpac. Build the project as normal (ctrl+shift + b) then alt tab to powershell and run the last command (the deploy script)
Use StudioShell (https://studioshell.codeplex.com/) to create a visual studio command to do the build then deploy which you can then map
(2) is closer to what you want but I personally prefer (1) as it is much simpler. The benefits for me for using (1) are:
The script is the same one I use in CI, QA, Prod etc to deploy the dacpac so it means I test it lots (and lots)
I see any errors and warnings easily and can keep an eye on when objects are being re-deployed over and over so I can fix the issue rather than not noticing and the deploy times getting longer and longer
I see similar questions like this quite a lot so I thought I would write up my thoughts properly on this: https://the.agilesql.club/blog/Ed-Elliott/Visual-Studio-SSDT-Publish-My-Personal-Best-Practices
Whatever you do (this or something else) follow up with your experiences, I (at least!) would find it interesting!
ed
I found two alternatives:
Right-click the solution, select "Startup Project", "Multiple startup projects", and make the database project one of them.
Right-click the solution, select "Project Dependencies", and make the database project a dependency on one of the other projects that will be built.
Related
I have 3 stages (dev / staging / production). I've successfully set up publishing for each, so that the code will be deployed, using msbuild, to the correct location, with the correct web configs transformed - all within Jenkins.
The problem I'm having is that I don't know to deploy the code to staging from what was built on dev (and staging to production). I'm currently using SVN as the source control, so I think I would need to somehow save the latest revision number dev has built and somehow tell Jenkins to build/deploy staging based on that number?
Is there a way to do this, or a better alternative?
Any help would be appreciated.
Edit: Decided to use the save the revision number method, which parses a file containing the revision number to the next job -- to do this, I followed this answer:
How to promote a specific build number from another job in Jenkins?
It explains how to copy an artifact from one job to another using the promotion plugin. For the artifact itself, I added a "Execute Windows batch command" build step after the main build with:
echo DEV_ENVIRONMENT_CORE_REVISION:%SVN_REVISION%>env.properties
Then in the staging job, using that above guide, copied that file, and then using a plugin EnvInject, to read from that file and set an environment variable, which can then be used as a parameter to the SVN Repository URL.
You should be able to identify the changeset number that was built in DEV and manually pass that changeset to the Jenkins build to pull that same changeset from SVN. Obviously that makes your deployment more manual. Maybe you can setup Jenkins to publish the changeset number to a file and then have the later env build to read that file for the changeset number.
We used to use this model as well and it was always complex. Eventually we moved to a build once and deploy many times model using WebDeploy. This has made the process much more simple. Check it out - http://www.dotnetcatch.com/2016/04/16/msbuild-once-msdeploy-many-times/
Currently I package my changes using the publish wizard in Visual Studio and take those files to the server and run the deploy batch file in command line.
What is the best strategy to use if I have issues in the deployment and I want to revert back my website/service to the last working state?
Since your deployment is a manual process, it would probably be best to create a backup zip or copy of the webroot - this could be added as a command in your batch file before the other commands.
Alternatively, you could create a label in your source control system each time you deploy which would give you the ability to re-deploy a previous version. I would only advise this approach though if you have some sort of CI process in place to guarantee that the label is done prior to each deployment/release, otherwise your process is dependent on the person deploying remembering to create that label - if they forget, then you can't restore that previous version.
Is there any way in ASP.NET website project, that allow to publish it from command prompt and I can continue working on project, or if it is not easy to use , at least speed up my publish task?
I know about the auto publishing tools like TFS or CruiseControl, so please don't tell me these ways.
I am thinking to create a .bat file , that I'll run everytime I have to publish. but it should not take changes made by me during its running process.
asp.net single file publish
I really like the Answer given by Ludwo, providing more information on that would be very helpful.
You can use MsBuild to publish your websites in parallel. Start with this article. It is about publishing one website using MsBuild. Define your projects inside ItemGroup and use MSBuild task this way:
<MSBuild Projects="#(YourProjectsToBuildInParallel)" BuildInParallel="true" ...
The final step is to enable parallel processing for MSBuild task.
Open another Visual Studio to continue :P. Publishing mechanism can detect updated and can send only changes. So dont upload full site everytime, if its really disturbs you.
Use source control and a build server mechanism. The build server should be able to pull from source control when you commit a change, build the project, do any unit tests you may/should have, and then deploy to a test site.
Depending on which build server platform you use you may or may have to do varying amounts of work. In the past I have used Bamboo by Atlassian. Fantastic product but you have to configure the deployment using MSBuild - it's fine but it can take some time to get it perfect. I am sure there are some good examples out there for it.
How it will work for you:
When you are finished working on a file/issue you can commit your changes. The build server will then detect these changes and wait a varying amount of time (waiting for you to commit more) e.g. 3 minutes, check out your changes, and deploy. You can set up notifications when the deployment is done to goto your testing team - with a link in the email saying where the site is, and what the change that occurred (based on your SVN commit log).
So your net effort is to check a file in with a correct comment - and you are finished.
I have 2 build configurations in one project:
Build & Test Code
Deploy Code
I want Deploy Code to run only if Build & Test Code built successfully, so I set up a snapshot dependency.
Does a snapshot dependency mean that Deploy Code will check out the same SVN revision as Build & Test Code and then run the NAnt script against that checkout, which will not contain the compiler generated post-build files? Or, will a snapshot dependency on Build & Test Code from Deploy Code mean that the NAnt will run against the post-build, working directory files of Build & Test Code on the build agent?
UPDATE:
It seems if I put a snapshot dependency on Build & Test Code for Deploy Code and I have a build of the latest revision for Build & Test Code, my NAnt script will deploy the post-build files for that build of Build & Test Code.
I would still like to confirm that I understand the concept, as I don't really understand the Team City documentation. I think I should probably make sure Deploy Code runs on the same build agent as Build & Test Code, otherwise I might run into a case where Deploy Code checks out the SVN revision and then just deploys the pre-build code files. Is this correct?
My confusion is mainly because it seems you have to have a VCS setup for Deploy Code. Is that because it needs it to compare revision numbers to the snapshot dependency?
From the Snapshot Dependency section of the Dependent Builds doco page:
A snapshot dependency from build configuration A to build
configuration B enforces that each build of A has a "suitable" build
of B so that both builds use the same sources snapshot (used sources
revisions correspond to the same moment).
So the idea of a snapshot dependency is that you can run a build against exactly the same codebase as another build which has successfully run against it.
If you want the "deploy code" build to run only after "build and test code" has successfully run, create a snapshot dependency in the second build and make sure it's set to "Only use successful builds from the suitable ones".
Keep in mind that this has nothing to do with artefacts; the second build will simply pull the same codebase and recompile it all over again. If you want to deploy the artefacts created from the first build, then you want to be looking at artefact dependencies instead. This is just what Paul has written about in his answer and is the correct approach.
Regarding your update, it sounds like those post-build files are only available because they're still on the build agent after the first build. Try running the first build then "cleaning sources" on the agent and running the second build. You'll find the original compilation output is no longer there and it will fail. This is important because if you have multiple build agents or go some time between the two builds you simply can't rely on the output that isn't saved as artefacts still being there.
And yes, the TeamCity documentation is confusing :)
I have a very similar setup in TeamCity except that I use MSBuild not NAnt but I use the same 2 step build process and if I explain how I've configured it then hopefully it will allow you to understand what you need to do.
So in my setup, Build 1 pulls the code from source control, compiles it and runs the unit tests. It then publishes all the files required for deployment as artifacts.
Build 2 has a snapshot and an artifact dependency on Build 1 and this means that it pulls no code, it just simply takes the artifacts from Build 1 and deploys them.
In practice this means I can trigger Build 2 and one of two things happen. If Build 1 is up to date then it simply deploys the artifacts from the last successful build of Build 1. However if Build 1 is not up to date then TeamCity will automatically trigger Build 1 and then run Build 2 straight afterwards using the artifacts from that build.
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.