currently I need a little hint for test running a RoR + Angular Application. And with test running I talk about that the "project owner" can see the current version of the project. For large projects with a lot of developers we had a build server, where the server got the current version from the git repository and deployed it as a "nightly build".
For projects where I'm the only developer I use dropbox to synchronize my working directory to a server, that is accessible for the project owner.
But now I'm working on a small project with 2 other developers. The build server is too much and the dropbox solution, well it's not going to work, because every one of us has a different state. And working on the same Dropbox directory is a no go.
So what's the best solution?
Consider running it on Heroku, which has a free tier. Once set up properly, deployments can be done by simply pushing to your Heroku git remote, or you can set it up to watch an existing remote repository branch (such as a particular branch on Github).
Or you could run it on your own machine. If you are behind a firewall you could set up a tunnel so your team can see it, with something like ngrok.
Related
I am trying to find the best way to achieve the following scenario;
I am currently working on getting a complex enterprise web application that consist on:
DB
BPM Engine
SOA Engine
Reporting Engine
Web Application Server
IDE
The applications is currently running in non-prod and prod environment but each environment is independent (no infra as a code, and deployments go from dev -> ... -> prod).
When a new developer comes in, they can't run the system in their local machine as it involves too many components (will come to this later). So they do development in their local machine and to test, they need to publish and deploy to dev. Test, rinse and repeat.
I am currently working on reverse engineer the whole thing so I can get it working on my local machine provided that I can install and run all the components. I am nearly there after fiddling with a lot of configuration, settings, etc.
This work I would like others to use, so they can also run the project in their local machines. In fact, since we will be migrating soon, I would like to pack the whole thing in a way that I can deploy it anywhere (the app already working and configured) and parametrised somehow whether is DEV, SYS, UAT, PROD. This, according to my understanding is what a docker image would do for you correct? You do all the work and then you create an image out of it? Then you can have this image running in a container and that way, other people can 'reuse' your work?
Is this the correct way of doing it? Any hints / comments would be appreciated
Apologies for my writing.
I've been digging for hours and i haven't been able to find what i would think is a pretty common scenario.
I am attempting to deploy a Web Deploy Package to my existing Web Site\Web App via a TFS Release. The location of my existing Web Apps is mapped to a different drive. My source code on my web server is not in C:\inetpub lets say its in D:\MyFiles.
I'm open to using any TFS task to do this. It seems like my two options are:
Run Batch Script - point to myApp.deploy.cmd
WinRm IIS Web App Deployment
I've seen lots of examples of overriding the computer name via the setParamater file but I have not seen one example of how to set the target path for the package?
Again, i want to deploy a web package via a TFS release to D:\MyFiles. I've created the package and it deploys locally to c:inetpub, I would assume if I can get it to deploy to a specified Target location locally then when I run that same. CMD file from TFS release it will use that location on the deploy to server.
UPDATE:
So... this just started working. I'm not sure what the issue was but the WinRm Task didn't do the deploy on Friday but did the deploy on Monday. I'm thinking it may have been related to a FQDN for the server path? Honestly I'm not sure what fixed it or what to do with this post? The answer below by #Andy may help someone so I won't delete it. That link is a good one and it showed me how to perform IIS configuration with Web Deploy.
Thanks in advance,
Greg
Seems you are trying to change the physical path of an IIS site/app using MSDeploy.
Just try adding an additional command (appcmd) to the MSDeploy package manifest to change the physical path of the IIS site during the deployment:
<runcommand path="%windir%\system32\inetsrv\appcmd set app /app.name:"Default Web Site/app12" /[path='/'].physicalPath:C:\temp\app12" waitInterval="5000"/>
Refer to this article for details:
WebDeploy/MSDeploy Quick TIP: Change IIS Site/APP Physical Path with MSDeploy
Folks,
We have got an enterprise application which uses Apache Service Mix for deployment. The application consists of various services and each is created as separate Maven project (bundle).During development, we are actually building each service separately and in-order to deploy it,its being put in the deploy folder. Also, we have to uninstall the bundle from the container(say; karaf) and then install it again from the console to bring the new changes in effect. This is fine during the development phase.
Now we want to deploy the code to an UAT environment (Amazon EC2) for the client to do the testing. We are now confused about how to deploy the bundles to the remote environment. Do we have a standard approach for CI using Jenkins(or some other tool) to automate the build and deploy process , so that someone who has no knowledge about the bundles(SMX) can deploy the code. We are using Github for source code management.
We have searched a lot in this regard and couldn't find any resources which provide some leads/hints on this.
Any help/tips is highly appreciated. If you need more info, I can give more details.
~Ragesh
We do have exactly similar setup and we use the Jenkins to build and let the Sysadmin to copy the bundles to one server and then he enables the rsync to rest of the servers.
Remember, always deploy the dependent bundle first and then remaining ..
Since we have this dependency ,we can't go automating this process.
I'm trying to deploy my application to production on my laptop but i keep getting a
No application found matching remotes:
git#github.com:this_is_the_old_github_remote/Application.git
so this used to be the old remote but it was recently changed
so this makes sense but how do I fix this issue and tell it to go to the new one
There are a couple of ways to work around this issue.
Update the repository's config to have the proper URL for your remote branch.
Tell the ey cli tool which application and environment you are trying to deploy to.
The first method is probably better so you do not have to worry about this in the future.
To update your repository configuration you simply need to run git remote set-url origin https://url.to/new/repo/Applicatoin.git
Once the repository in your git configuration and the Engine Yard dashboard match, you should be able to deploy normally.
To work around this issue via the Engine Yard CLI utility, you will need to run ey deploy --app=<Application Name> --environment=<Environment Name>.
Please keep in mind, regardless of which method above you use to work around this issue, Engine Yard's automation will pull the application from the repository you configured via the dashboard.
Updating the remote on your git configuration does not update Engine Yard's configuration.
If your local copy of the repository has changes that have not been pushed to the remote repository configured at Engine Yard, the changes will not propagate to your instances.
If you continue to run into any issues deploying, please feel free to contact us via http://support.cloud.engineyard.com or in IRC on irc.freenode.net in #EngineYard.
I am developing a ruby on rails website using heroku and git.
What tools and features should I use to set up the following simple development process?
CODE > CHECK-IN > AUTO TEST > AUTO DEPLOY
I check my code into my repository (preferred option, hosted git like github)
Tests are automatically run AND website is deployed in my staging heroku app
If tests pass, the website is automatically deployed on my production heroku app
If tests fail, I want to be notified somehow.
How would you do this?
CircleCi offers exactly what you need. We'll run your tests on every push, deploy them if they pass (to Heroku or using Capistrano/Fabric/anything really), and send you notifications if they fail.
to preface I am one of the founders of Codeship (https://codeship.io), which is a service that supports exactly this.
But more on topic, basically there are 2 different ways I think this could be implemented (please keep in mind that all branch names I use are arbitrary and can be named totally different):
staging/production in one go
Whenever you push to your master or a specific deploy branch you run your tests and if all of them pass you first deploy to your staging app, run separate tests (Selenium or sauce labs is great for that) and if that works out including migrations you push to your production app.
This is great as the latest version is always available in production and we use this cycle for a long time now. Works great for us. The downside is that pushing to a staging heroku app takes some time. If you want to run the migrations against a copy of your production data this takes even more time. It's not an eternity, but it takes a couple of minutes.
staging/production as separate steps
You could have separate staging/production branches which are deployed to the respective heroku applications. This has the advantage of being faster and you can control when to release certain parts. Especially for applications where you want external feedback before deploying to production this works great.
We support all of that at Railsonfire, but we are currently working on a new version of our service which is way better. We integrate really well with Heroku so you don't have to think about that (but still have the option to do it yourself in any way you want)
We use Integrity. It is a pretty simple solution - it won't do everything under the sun, but it's quite easy to set up and handles the most common use cases/features. It's also pretty easy to hack on, if you want it to do more.
Integrity states:
Heroku is the easiest and fastest way to deploy Integrity.
However:
NOTE
It isn’t possible to access repositories over SSH on Heroku
This is because your Integrity app will need an SSH key. It's not impossible, but definitely a few hoops to jump through. You'll need to give Integrity a private key and put it in the app, and then hack Integrity to use that ssh key when it initiates the git clone.
Of the things you listed, the automatic deploy is probably the thing most people would not expect their CI server to do (and Integrity does not provide out of the box). You'll need to configure git to use that ssh key and initiate a git push from the proper location (the checked out repository).
Unfortunately I don't know the details of how to do this--we actually run Integrity on a VPS.
There are many tools in the market that do this. SnapCI offers deployment pipelines that let you push every commit through tests and then subsequently into staging and production as different stages of a deployment pipeline. We also have full support for test parallelization, building branches and pull-requests.
Well, there is Hudson which provides a git plugin as well as scripting support. The rest is configuration, I would guess.
Hudson: http://hudson.dev.java.net
Try Heroku-Bartender. A write-up here.