I'm working on a website using PhpStorm. For a long time I developed it locally, but then I got hosting and a remote ftp server.
I created a new project in PhpStorm with the settings for remote host, and I found that deploying code takes long time (over a minute) before I can see the result, which is quite uncomfortable when debugging.
Is there any possibility to work with code on a local server, and, when I think that the project is ready for deploy, just send it to the server.
I understand, that I can just work in two different projects and just deploy the "ready" version to server via FTP, but maybe there is some more comfortable way?
There is several answers to this question, and most of them opinion based but i will try and keep it objective.
Case 1
A big corporation gives every developer a sandbox, to test their code from, the corp requires every developer to keep their code on the sandbox.
Using mounted drives could be extremely slow. Especially when PhpStorm is indexing.
Case 2
An easy way to keep an auto backup of your code it to use the build in (s)ftp(s) upload/deploy.
Solution
In both cases you could use the auto deploy feature that saves every changes to the server, that way the deploy doesn't take over a minute, but is usually already there before you know it.
I cannot recommend to use the deployment for Production as it will not pass through your version control, SAT, security setups etc. In that case I would suggest something like rocketeer etc.
EDIT:
As for 2 projects, well you can define 2 different deployment servers, and use the default one for your testing, with auto upload or something, and then the other one can be selected from the deployment menu.
Related
I have introduced branching/merging to my team and have talked before about how it would be great to automatically build and deploy code checked into the staging/master branches, but I'm a junior dev, not very ops-y.
The trouble I'm having, is that we create intranet applications and store them on our own VM's which we have access to, but we also have load balancing which is causing me grief!
I can get a build to automate (well, I haven't got all the bugs figured out but I'm working my way through them) - and I can even get the build to automatically create a zip file ready for deployment.
Is it possible to configure several servers for deployment?
I.E
1) I check in some code to stage
***Automatically***
2) Code builds
3) Build completes, Unit tests run and they complete
4) Code is packaged into a .zip
5) .Zip is deployed across the three load balancing servers (all with the same file path).
***
Maybe worth noting we currently have our TFS server running Visual Studio so the code is built on the same server it is all stored, but this is not the server we run live code from.
Any help or tutorials specific to my setup would be GREATLY appreciated, I really want to turn this departments releasing strategies around!
I am going to address only the deployment aspect. There are a lot of different ways that this can be handled, such as:
Customizing the build template
Writing custom .Net code and inserting it into the build template (which would also involve customizing the template)
Creating a Batch or Powershell script set to run after the build completes
Using a separate tool such as OctoDeploy or Release Manager to handle the deployments
The first thing you need to do is separate the build and deployment steps in your head. While they are tightly coupled in your model, they are two totally different tasks that need to be handled different ways.
The second thing is to stop thinking like a developer when it comes to the deployment portion. While there will likely be a programmatic solution, you'll need to identify the manual steps first.
You stated that you're not very ops-y, by which I assume you mean you're more Developer and not Systems Analyst. If that is the case, then the third thing you'll need to do is get someone who is involved, such as your current release team.
There are 3 major things that need to be done then:
EVERYTHING needs to be standardized. If you can't standardize something, then standardize the way that it's non-standard (example: You have a bulk list of servers you need to deploy to, and you need to figure out which ones to deploy to based on their name, which can be anything. In that case, a rule needs to be put in place that all QA servers need to have QA in their name, User Acceptance servers need UAT, Production need PROD, etc.).
Figure out how you're going to communicate from the build to the deployment, which builds are going to deployed, to which servers, and where the code is going to be picked up from
You need to document every manual step, and every exception to those steps, and every exception to those exceptions.
Once you have all those pieces in place, you need to then go through each manual step and automate it, whether that's through Batch, Powershell, or a custom-built application. Once you have all the steps automated, you'll have both the build and deploy pieces complete.
After you're able to execute a single "manual" automatic deployment to a single environment, you're then ready to figure out how you want to run it for multiple environments. This can be as complex as an XML file that is iterated through, to simply calling the same command multiple times with different parameters.
A quick summary of how I've done this at my current job (where using a third-party deployment tool was not an option):
Created a tool using .Net WinForms to allow us to "manually" run automated builds (We use the interface to determine the input parameters, and the custom classes under the hood do all the heavy lifting. These custom classes are in a separate project that builds to their own dll. This also allows us to test tweaks and changes to the process in a testing environment before we roll it out to our production build server)
Set up an XML file for each set of environment (QA, UAT, Prod, etc.) that contains all of the servers that need to be deployed to in that environment, including destination paths, scheduled tasks, and Windows Services
Customize the TFS build template and include the custom classes created for the custom tool, which will read the XML file and iterate through each server entry to perform the deployments
I'm more than happy to help with more specific examples and assistance, I look at things a bit different than most people and it helps when it comes to release management.
I can't wrap my head around how I'm supposed to use ColdFusion Builder 3 (akin to Eclipse).
Up until this point, I've been using Dreamweaver 5, which is getting 'long-in-the-tooth', and I wanted to give CF Builder a try.
So, in Dreamweaver, it's pretty simple: you setup connections to servers using credentials... There's a Local path, which is the local copy of your code, and the webroot of the Server which is the 'live' copy of your code. Basically, you make a change to the local copy, and PUT the change to the Server. Easy peasy lemon squeezy, right?
But, how does this translate to ColdFusion Builder 3?
Just to give you an idea of our infrastructure.... we have Development and Production. Each of these boxes has multiple web instances, example: Accounting, Human Resources, IT. Each of those web instances could have multiple applications.... I'm only considered about my instance, IT, on both the Production and Development servers.
Is a workspace supposed to represent an instance on a web server?
In CFBuilder, should I configure 1 server per web app?
Is a project supposed to represent a web app?
Am I supposed to use drive mappings to the inetpub wwwroot for access to web applications? Is it even considered kosher to have a drive mapping to the web root? \server\c$\inetpub\wwwroot
Where do I keep my local copy of my code?
How do I move items from Development to Production?
My main confusion is with workspaces, projects, and servers... My intent is to debug and 'view page in browser' from CFBuilder.... However, when you setup a server, under Server Mapping and URL Prefix, you're supposed to indicate the Local and Remote paths, plus this is not directly related to the physical location of the project.... and as I've mentioned, there's multiple instances, multiple applications, and the development box is not my local machine, it's a remote server...
I would really like to know how others have made this work for them.
I really don't mind this question even though it's not directly code related because I've been using ColdFusion Builder (CFB) for years and there just isn't enough good documentation out there. I now enjoy a great experience with CFB thanks to blog posts and sharing experiences with other devs :)
My setup: CFB3 running on Windows 8.1, dev server running on a Virtual Machine so it is treated as "remote server" just like yours. I also update remote staging and production servers (although not directly from CFB).
First, let's set some reasonable expectations: Dreamweaver and CFB are very different in that CFB focuses on programming and Dreamweaver on design. CFB is built on eclipse and therefore has the advantage of benefiting from most eclipse plugins.
Your question is specifically about how to set up your projects in CFB using 2 remote servers (dev and prod). It's different for everyone but I'll share my setup with you. (sidenote: My projects are also stored in Git repositories - 1 repo for every app)
Starting from the top: A workspace in CFB deals with your whole eclipse application, not just your projects. The most important things kept in this directory are snippets and plugins. You do NOT need to keep your project files in here. This is merely the main directory where all of your settings are kept. You are not required to have more than 1 workspace (I only have one). Why would you need more than one? You may be multifaceted programmer who needs to keep separate workspaces using separate tools (like different plugins, snippets, window layouts...)
To answer your next question (1 server per web app), all you need to to is configure your dev servers in the "CF Servers" tab. You need to add 1 server per web instance for every instance that you'd like to test on. Hopefully, your dev server has RDS enabled (very helpful for remote database and file viewing, just like in Dreamweaver). During configuration, don't worry about Mappings or Virtual Host Settings (I have another recommendation later). Once configured, you'll be able to assign that server to a project.
Drive mappings: I would never recommend mapping to the webroot of a shared dev server. If you were to use that drive map as your local directory, your changes will be made directly to the development server. What you want to do is create a new project by right clicking in the Navigator area and select Import > Other > FTP. Follow the steps, choose anywhere on your local drive to store the files, then choose "New project" at the end (this will add the .project file necessary for CFB to control the project).
Once the project is created, right click on it, select ColdFusion Project and choose the CFML Dictionary version you'll be using (CF11, 10, 9...). Then, select ColdFusion Server Settings and choose the dev server. This is necessary for testing.
What you now have is a local directory with your app and eclipse knows about the remote server. In order to synchronize, you right click on the project, go to Team and synchronize from there. For detailed information about synchronization over FTP, see the help section "Guide to WebDAV and FTP".
Moving to production is not as simple as it was in Dreamweaver. The FTP configuration information only allows for 1 connection (thus giving you a list of files synchronized between your project and the dev server). Therefore, you'll need a third party FTP client to synchronize between your local project and your prod server.
As promised, my last entry will be able the "debugging" which is why I said to skip the mappings and virtual host settings in CF Server config. I really, really recommend using a third party paid plugin called FusionDebug (http://www.fusion-debug.com/). This plugin facilitates the setup and allows you to step-into all of your code (which doesn't work so well in native CFB). There's a 30 day trial and I recommend you try before your buy (or license for a year in this case!)
I have a REST API endpoint written in Go and I am wondering what is the best way to deploy it. I know that using Google App Engine would probably make my life easier in terms of deployment. But, suppose that I want to deploy this on AWS. What options/process/procedures do I have. What are some of the best practices out there? Do I need to write my own task to build, SCP and run it?
One option that I am interested in trying is using Fabric to create deployment tasks.
Just got back from Mountain West DevOps today where we talked about this, a lot. (Not for Go specifically, but in general.)
To be concise, all I can say is: it depends.
For a simple application that doesn't receive high use, you might just manually spin up an instance, plop the binary onto it, run it, and then you're done. (You can cross-compile your Go binary if you're not developing on the production platform.)
For slightly more automation, you might write a Python script that uploads and runs the latest binary to an EC2 instance for you (using boto/ssh).
Even though Go programs are usually pretty safe (especially if you test), for more reliability, you might daemonize the binary (make it a service) so that it will run again if it crashes for some reason.
For even more autonomy, use a CI utility like Jenkins or Travis. These can be configured to run deployment scripts automatically when you commit code to a certain branch or apply tags.
For more powerful automation, you can take it up another notch and use tools like Packer or Chef. I'd start with Packer unless your needs are really intense. The Packer developer talked about it today and it looks simple and powerful. Chef serves several enterprises, but might be overkill for you.
Here's the short of it: the basic idea with Go programs is that you just need to copy the binary onto the production server and run it. It's that simple. How you automate that or do it reliably is up to you, depending on your needs and preferred workflow.
Further reading: http://www.reddit.com/r/golang/comments/1r0q79/pushing_and_building_code_to_production/ and specifically: https://medium.com/p/528af8ee1a58
We have a c#, .NET 4.0, windows application which we deploy to a terminal server. (Developed using VS 2010). This application makes use of several WCF services sitting on another server.
Our users access the front-end via remote desktop session. (They all have a .RDP file on their desktops.)
My question is regarding the deployment of this front-end. Currently, if we need to do an emergency deployment during business hours, we need to kick all the users off that are hooked into the app (as they are using the dll's that we need to replace). This is not ideal, obviously. We work in quite a business-critical environment, so these deployments are unavoidable. I've investigated ClickOnce, but have read that you cannot use this with terminal services application here. (Which kind of makes sense since it's essentially one app being "accessed" by several clients...)
I would like to be able to do a "silent" deployment whereby the user knows nothing about the fix until they restart their instance of the application. I'm not sure this is even possible?
I would appreciate any guidance or suggestions on this!
Yep, I do this all the time with a RD app -- you just need to move or rename the DLLs instead of deleting them. Windows allows moves and renames when DLLs are in use, but prevents you from deleting them. If you use Windows Installer to deploy your app, it will do the moves automatically (and delete the old versions when the system is next rebooted).
Once you replace the DLLs this way, existing sessions will continue to use the old, renamed versions, and new sessions will use the new versions. Of course, depending on how many DLLs you have, how long it takes your app to load them into memory, and how much activity you have on your server, you could run into a scenario where the app loads some of the old DLLs and some of the new ones when you're in the middle of updating them, but that would likely be rare.
I have some questions around the best mechanism to deploy MVC web applications to different environments. Previously I used setup projects (.msi's) but as these have been discontinued in VS2012 I am looking to move to an alternative.
Let me explain my current setup. I currently have a CI setup using TFSBuild 2010 with Team Foundation Server for source control.
A number of developers work on their local machines and check in to the TFS Server. We regularly deploy to a single server dev environment and a load balanced qa environment with 2 servers. Our current process includes installing an msi which carries out some of the following custom actions:
brings current app offline with the app_offline.htm file
run in database scripts (from database project in the solution)
modifies web.config (different for each web server of qa)
labels the code
warmup each deployed file via http request
etc
This is the current process. Now I would like to make some changes. Firstly, I need alternative to msi's. From som research I believe that web deploy via IIS and using MsDeploy is the best alternative. I can use web config transforms for web config modifications. Is this correct and if so, could I get an outline of what I need to do?
Secondly I want to set up continuous delivery via TFSBuild, I have no idea how this may be achieved, would it be possible to get an outline of how it can be integrated in to my current setup? Rather than check in driven, I would like it to be user driven following check in. Also, would it be possible for this to also run in database scripts from a database project in the solution.
Finally, there is also a production environment, but I would like to manually deploy this - can my process also produce an artifact that I can manually install?
Vishal Joshi has some information on his blog that is reasonably good, http://vishaljoshi.blogspot.com/2010/11/team-build-web-deployment-web-deploy-vs.html. It does have the downside that your deployment password is include in the properties you pass to msbuild.
Syed Hashimi has also posted some information on this in another questions Team Build: Publish locally using MSDeploy.