I have a bunch of Integrationtests on Travis, that I need to run after my Ruby on Rails app has been deployed to Heroku. How can I do that?
I tried to use the HTTP-POST-Method but Travis required custom headers and JSON body and Heroku does not support both. Is there another way?
I can think of couple of solutions, but none is perfect.
One: You can create simple app that will translate normal Heroku deploy hook into format acceptable by Travis. Of course you need to host it somewhere, but it is a great use case for Amazon Lambda or similar solution. If you ever wanted to try doing serverless I think you have a perfect case. And the cost of hosting will be almost nothing.
Two: You can use release phase on Heroku. Create a script bin/notify-travis and this to your Procfile release: bin/notify-travis. The problem is how to get all the information about deployed code like commit sha. For that you can enable lab feature called dyno-metadata. It will inject additional config variables, one is HEROKU_SLUG_COMMIT which contains commit sha. If more data are required, then this solution may not work. Make sure that bin/notify-travis returns 0. It will run just before deployment. And if fails, your code won't be deployed.
Three: You can find or write custom buildpack that will send webhook to Travis. The problem is that it will run during build phase. In case of errors your code may not be deployed, but you will send a webhook. And also it can be problematic to get all required information about the build as in solution two.
So you have some options. I guess the first one is the best, but it may not fit your other requirements.
Related
I've been working with RoR for a while but now I need to work with designers and other developers. Is there a tool like github or something like dropbox where you can share with your team the files but with a URL where you can check live any change. For example for my own I just run Rails s and I can see what happen on my localhost but for a designer it isn't that simple. And also we don't want everybody running his own rails project on his localhost.
So is there a tool or what do you do guys when you have to work with others collaborates?
You consider to use a staging environment?
A staging environment (stage) is a nearly exact replica of a production environment for software testing. Staging environments are made to test codes, builds, and updates to ensure quality under a production-like environment before application deployment. The staging environment requires a copy of the same configurations of hardware, servers, databases, and caches. Everything in a staging environment should be as close a copy to the production environment as possible to ensure the software works correctly.
See the Font
To use it, i recommend you a application like Heroku, after configure, you can 'deploy' your app commiting in a branch (its not real time, but works for your case).
If you have a VM, i recommends you this tutorial: https://emaxime.com/2014/adding-a-staging-environment-to-rails.html
Open questions like this are not really best placed on StackOverflow, which is geared more toward solving specific issues, with provided code examples and errors etc.
However, in answer to your question:
I see you mention Github in your question, but do you fully understand the underlying concept of Git Version Control, or is there a speficic reason as to why it doesn't meet your needs? As far as I believe, it's main purpose is to solve your exact scenario.
https://guides.github.com/introduction/git-handbook/
AWS Opsworks lets you deploy an app. The deployment seems to deploy the master branch always.
How can I make it deploy a git tag?
Thanks
There is no elegant solution to this. It's a shame OpsWorks doesn't let you specify branch/tag at deployment time.
EDIT: After some digging around with OpsWorks/Chef/Ruby, you actually can deploy a specific tag relatively simply. Either of the two methods below are still valid.
You can deploy a git tag in one of the following ways:
Method 1: Specify in App settings
Before deploying, edit your App, and change the Branch/Revision value to tags/1.2.3 where 1.2.3 is the tag you want to deploy.
Save changes, then deploy your app as normal.
Remember to manually change this each time you deploy!
Method 2: Pass custom JSON on deployment action
Include the following custom JSON when you deploy your app
{"deploy": {"myapp": {"scm": {"revision": "tags/1.2.3"}}}}
where myapp is the Short name of your app and 1.2.3 is the tag you want deployed. Don't forget to include this custom JSON each time, or your deployment will default to whatever you have in your App:Branch/Revision.
Further Thoughts
For apps in build/test, you could specify develop as your Branch/Revision in App Settings, and not worry about using custom JSON each time. This will always deploy the head of develop for you.
For apps in production, you could have master as your Branch/Revision, then specify the custom JSON at deployment time. This way, if you forget to include the custom JSON, at least it will deploy the latest revision from master, which most of the time should be the same as your latest tag.
It is worth noting that if you add new instances to your layer (manually, or automatically according to your layer rules), the default behaviour would be to deploy a fresh version of your app according to the settings in App:Branch/Revision.... so actually, you'll need to be mindful of both methods depending on your exact requirements.
Have you check this? You can check Branch/Revision
section it is showing how you can deploy according to branch http://docs.aws.amazon.com/opsworks/latest/userguide/gettingstarted-simple-app.html
I am actually dealing with this very same problem right now. We are moving our testing / staging environments into OpsWorks to leverage their time based instances for cost savings.
The way around this I went was a small command line ruby script to poll AWS to show me the stack list, then I can select the layer, app and the instances I want to deploy to. The script then asks for the branch name of the repo to deploy, and pushes a deploy over the AWS CLI to OpsWorks to handle.
This is all done over the AWS CLI. I will see about making this available online and post a link if it is clear with the boss.
On edx.org there is Software as a Service course that grades all submitted assignments.
You upload a zip-file with a Rails project and they run a bunch of integration and unit tests.
How do they do it?
My thoughts are they mount an uploaded application as Rails engine. Is it possible to test one Rails app within another? I'd like to create a similar service, but I don't know what to start with.
I would imagine you could do this in a similar way that Jenkins runs continuous testing on a project. Where each project uploaded to your site gets expanded into a workspace, and then you shell out and execute commands. But that allows for a lot of variable configurations and complexity that probably doesn't make sense in the scope you've proposed. It also doesn't protect your underlying OS from the projects your testing.
You could also probably use an application container like docker and manage each uploaded application that way as well, which would keep everything self-contained, and isolate the application from the OS. It also puts the onus on the developer to package and manage dependencies correctly. I'm guessing they are probably using docker or something similar, here's an example Using Docker for MOOCS
At the point you want to capture the test results and report them back, I'd think they probably use something similar to the Junit formatter for Rspec or they just parse the rspec output directly.
I am newish to Rails and GitHub and struggling with managing two coders' development logs. Specifically:
How do I merge two developers development logs?
Can I automate their merger? Or can I differentiate them in some Railsy or GitHub Flowy way?
The Rails app I am developing on command line CentOS 6 is being worked on by another developer. We are using a private GitHub repo to help us manage our codebase and are trying to follow The GitHub Flow.
This strategy works well for almost every aspect of our project. The only major problem I've run into with this so far is that our development logs are (of course) out of sync. For instance, he branches from master, then I do. Then he merges to master, then I do, but my merge will fail, citing the automatic merge failure on log/develoment.log. Our logs will be structured like this:
log/development.log - mine
Shared: (Tens of thousands of lines of code from master branch point)
Not: (Thousands of lines of code unique to my branch)
log/development.log - his
Shared: (Tens of thousands of lines of code from master branch point)
Not: (Thousands of lines of code unique to his branch)
So, I find going through this manually, even with diff tools like git mergetool, impractical because of the volumes of code involved. (Am I simply too much of a vim novice to be able to put this to good use? Do others find this trivial?)
Is there a git or rails development strategy we can employ to keep these files without them clashing? (ex: some tinkering with Rails configuration to designate 'Development1' environment vs. 'Development2' environment)?
Is there some command line tool that merges two clashing logs based on time last updated? I'm imaging a tool that, given two clashing git-tracked documents can merge them by comparing the branch point/time, using that as the 'shared' base and adding in the remainder based on which was more recently updated (more recent > appended last). A more advanced version would walk back through commit history to append updates based on commit timestamps.
Logs are useful for your own purposes:
check requests sent
check params sent
check correct matching url/controller-action
check sql queries
check your own stuff (you can log things if you desire)
So because its for your only purpose, no need to pollute your repository with it: add log folder to your gitignore.
There is a recommended gitignore for Rails projects here.
BTW, if logs in console are enough for you, save your disk space and add:
config.logger = Logger.new(STDOUT)
in development.rb
I have inherited a project with a local development environment that has code specific to that machine, and which is different for the production server. Even though the majority of it is contained in constants and the rest is in the tests, every time I commit from development and update in production I'm going to have to make the same changes in production. Fortunately this is an internal tool with low volume.
I guess I could write a script to automate it but I'm hoping there's a better solution. Anyone else solved this problem?
These questions are similar but not asking the same thing, just so you know I looked:
(1) make changes to a production database
(2) transferring changes from dev to prod
Edit: Nelson LaQuet put me on what I believe is the right track, which led me to Configuring Rails Applications. However, I am unsure how to reference my FormController < ApplicationController constants, such as MyExternalCodeDir, in config/environments/production.rb and config/environments/development.rb.
Also I do not want to be required to change every reference to MyExternalCodeDir to something like config.MyExternalCodeDir.
You abstract all environment settings (database connection/pathing/URIs) into a single file. Let's call it "config.ini"
Then you simply commit a "template" called "config.ini.template" that contains the structure of the config file clearly documenting what is expected at each value - and sensable defaults. You then commit this file.
After you do that, delete the current config.ini file that is specific to your location, and add it to svn:ignore. Now, when you copy and paste config.ini.template to config.ini, and change your settings, it is not going to be committed to the repository.
It adds an extra step per deployment, but must be done only once (unless you add/remove config options). This is the best and most standard way of accomplishing what you want.
I would move the constants' values that are environment specific in a configuration file, which would make it easier to handle. I would also keep the code in just one repository in the version-control system and manage the build outputs in two separate repositories: one for the test environment and one for production. That way I can manage my code base however I choose, and when I want to deploy I'll first commit to test, and then merge from test to production and at that point just diff the configuration file and keep the correct configuration for the production environment.