#codeship

This is intended to fill a few holes in Launch’s tutorial on adding badges for your project.  I’m taking a bunch of this directly from their tutorial and adding the parts that weren’t explicitly included, but were helpful, especially in getting my Codeship and Coveralls badges to turn green.

Codeship

Step 1

Sign into Codeship with GitHub, create a new project, and connect your GitHub repository.

Step 2

Select “Ruby on Rails” from the drop-down. Make sure to change the ruby version to the version your group is using in development.

rvm use 2.0.0 --install

Step 3

Click “Save and go to dashboard”

Now, whenever you issue a pull request, Codeship will build your app, run the tests, and then let you know whether or not the build has passed.

If you would like to learn more about how you can configure Codeship, check out the documentation.

Coveralls

Step 1:  Add the gem to your gemfile:

# ./Gemfile group :test do gem 'coveralls', require: false end

 Step 2:  Add to the top of your spec_helper file:

# ./spec/spec_helper.rb require 'coveralls' Coveralls.wear!('rails')

 Step 3:  Add to your .gitignore file:

/coverage

Step 4:  Turn on your repo on coveralls.io

Step 5:  In your Codeship settings, set your environment config variables (config vars) with your COVERALLS_REPO_TOKEN.  

Codeship Dashboard < Project Settings < Environment

Add ```COVERALLS_REPO_TOKEN``` on the KEY side and your token (from the coveralls site) on the VALUE side.

 Step 6:  Create .coveralls.yml file and add coveralls_repo_token:

repo_token: COVERALLS_REPO_TOKEN

Shoutout to Kelly and Tom for this helpful tip on keeping your coveralls repo token private. :)

Step 7:  Add the appropriate badge to your README (exact code for your repo can be found on coveralls.io)

Coveralls documentation

Code Climate

Step 1:  Add your GitHub Repository

https://codeclimate.com/github/signup

Hound

Step 1:  Add this code to .hound.yml in the root of your project directory:

AllCops:  Exclude:    - db/schema.rb  #DisplayCopNames: true AccessorMethodName:  Enabled: false ActionFilter:  Enabled: false Alias:  Enabled: false ArrayJoin:  Enabled: false AsciiComments:  Enabled: false AsciiIdentifiers:  Enabled: false Attr:  Enabled: false BlockNesting:  Enabled: false CaseEquality:  Enabled: false CharacterLiteral:  Enabled: false ClassAndModuleChildren:  Enabled: false ClassLength:  Enabled: false ClassVars:  Enabled: false CollectionMethods:  PreferredMethods:    find: detect    reduce: inject    collect: map    find_all: select ColonMethodCall:  Enabled: false CommentAnnotation:  Enabled: false CyclomaticComplexity:  Enabled: false Delegate:  Enabled: false DeprecatedHashMethods:  Enabled: false Documentation:  Enabled: false DotPosition:  EnforcedStyle: trailing DoubleNegation:  Enabled: false EachWithObject:  Enabled: false EmptyLiteral:  Enabled: false Encoding:  Enabled: false EvenOdd:  Enabled: false FileName:  Enabled: false FlipFlop:  Enabled: false FormatString:  Enabled: false GlobalVars:  Enabled: false GuardClause:  Enabled: false IfUnlessModifier:  Enabled: false IfWithSemicolon:  Enabled: false InlineComment:  Enabled: false Lambda:  Enabled: false LambdaCall:  Enabled: false LineEndConcatenation:  Enabled: false LineLength:  Max: 80 MethodLength:  Enabled: false ModuleFunction:  Enabled: false NegatedIf:  Enabled: false NegatedWhile:  Enabled: false Next:  Enabled: false NilComparison:  Enabled: false Not:  Enabled: false NumericLiterals:  Enabled: false OneLineConditional:  Enabled: false OpMethod:  Enabled: false ParameterLists:  Enabled: false PercentLiteralDelimiters:  Enabled: false PerlBackrefs:  Enabled: false PredicateName:  NamePrefixBlacklist:    - is_ Proc:  Enabled: false RaiseArgs:  Enabled: false RegexpLiteral:  Enabled: false SelfAssignment:  Enabled: false SingleLineBlockParams:  Enabled: false SingleLineMethods:  Enabled: false SignalException:  Enabled: false SpecialGlobalVars:  Enabled: false StringLiterals:  Enabled: false VariableInterpolation:  Enabled: false TrailingComma:  Enabled: false TrivialAccessors:  Enabled: false VariableInterpolation:  Enabled: false WhenThen:  Enabled: false WhileUntilModifier:  Enabled: false WordArray:  Enabled: false # Lint AmbiguousOperator:  Enabled: false AmbiguousRegexpLiteral:  Enabled: false AssignmentInCondition:  Enabled: false ConditionPosition:  Enabled: false DeprecatedClassMethods:  Enabled: false ElseLayout:  Enabled: false HandleExceptions:  Enabled: false InvalidCharacterLiteral:  Enabled: false LiteralInCondition:  Enabled: false LiteralInInterpolation:  Enabled: false Loop:  Enabled: false ParenthesesAsGroupedExpression:  Enabled: false RequireParentheses:  Enabled: false UnderscorePrefixedVariableName:  Enabled: false Void:  Enabled: false Style/AlignParameters:  EnforcedStyle: with_fixed_indentation Style/SymbolProc:  Enabled: false Style/MultilineOperationIndentation:  EnforcedStyle: indented Style/EmptyLinesAroundBlockBody:  Enabled: false Style/UnneededPercentQ:  Enabled: false Metrics/AbcSize:  Enabled: false

Step 2:  Then, sign in on the website and flip the switch for the GitHub repo that you want to activate.

Adding Badges to README

Make sure to change <YOUR_GITHUB_USERNAME>/<YOUR_REPO_NAME> with the correct info  

```

 [](https://coveralls.io/github/<YOUR_GITHUB_USERNAME>/<YOUR_REPO_NAME>?branch=master)

日本ではあまり利用者が多くないかもしれませんが、CodeshipというCIサービスがあります。今回はCodeshipとVAddyを組み合わせた継続的セキュリティテスト環境を構築してみました。

CicleCI連携の時と同様に、git pushしてCodeshipのジョブを起動させ、テストサーバにコードをデプロイ、そのテストサーバに向けてVAddyからWebの脆弱性検査を実施します。

今回も、 git push -> Unit test -> Deploy(Staging) -> VAddy test -> Deploy(Production) という流れで解説します。 Unit testが失敗した場合は後続の処理は行われませんし、VAddy testが失敗した場合も本番にコードがデプロイされません。

本番環境にデプロイされるのは、ユニットテストとWeb脆弱性検査をパスした問題のないコードのみになります。

前提

この記事では、Codeshipインスタンス内に立てたWebサーバに対しての脆弱性検査ではなく、Codeshipから別のステージングサーバにデプロイした後に、そのステージングサーバに対しての脆弱性検査をするパターンの説明となります。

2017年7月現在、PrivateNet版VAddyをリリースしておりますので、Codeshipのインスタンスに立てたローカルWebサーバにも検査実行できるようになりました。 PrivateNet版VAddyの詳細は下記をご覧ください。 http://blog-ja.vaddy.net/post/161798392486/privatenet-release

ステップ1

VAddyに検査対象のサーバを登録し、スキャンが出来るようになりましたらWebAPIのキーを発行します。発行方法はマニュアルを参照ください。

Codeshipのプロジェクト設定画面で、環境変数にVAddyのAPIキーなどを登録します。

登録する環境変数は、

VADDY_TOKEN

VADDY_HOST

VADDY_USER

の3つです。VADDY_HOSTはVAddyに登録した検査対象のFQDNです。VADDY_USERはVAddyのログインIDです

ステップ2

「Configure your tests」の画面に行き、Configure Test Pipelinesに、下記のように記載します。

gistにサンプルの設定ファイルを置きました。 https://gist.github.com/ichikaway/e20450fe1910f760c613

./unit-test.sh ./deploy-staging.sh git clone [email protected]:vaddy/vaddy-api-ruby.git cd ./vaddy-api-ruby ruby vaddy.rb && cd ../ ./deploy-production.sh

unit-test.shにてユニットテストを行い、deploy-staging.shでステージングにコードをデプロイ。 git cloneでVAddyのクライアントツール(Ruby)をセットして検査開始。 問題が何もなければ、deploy-production.shが実行されます。 unit-test.sh、deploy-staging.sh、deploy-production.shは適宜プロジェクト用のものを利用してください。

今回は、deploy-production.shという独自シェルでデプロイするように記載していますが、CodeshipのDeployment機能を使えるようであれば、使うと便利だと思います。

動作確認

git pushしてVAddyで問題がなければdeploy-production.shまで実行されます。

もし、VAddyの検査で1件でも脆弱性が見つかった場合はそこで処理が停止して、deploy-production.shは実行されません。

チャット連携も簡単

Codeshipの管理画面の、「Notification」メニューに行くと、連携リストがでます。ここでHipchatやSlackの連携を有効にすると便利です。

今回はHipchat連携を試してみました。 Hipchat連携に必要な情報を画面から入力しておき、コードをpushします。 VAddyの検査で脆弱性が発見されると、Codeshipのテストが失敗し、Hipchatにエラーが通知されます。 問題を解決して再度テストを実行し、テストをパスすると、Hipchatに成功通知がきます。

まとめ

このようにVAddyのクライアントを使えば簡単にVAddy連携できます。 既にVAddy Jenkinsプラグインは公開しておりましたが、最近のCI as a Serviceの流れもあったので、RubyでVAddy APIを操作するツールを実装して簡単に組み込めるようにしました。 VAddy API Rubyはオープンソースとして公開しておりますので、Codeship以外のサービスにも適用して連携できると思います。（CircleCI連携の記事はこちら） WebAPIの仕様書も公開しておりますので、独自のクライアントツールを作り、プロジェクトに組み込むことも出来ます。

It’s easy to combine VAddy with Codeship to set up an environment for continuous security tests. Just run git push to start a Codeship job, deploy your code to your test server, and then test for web security vulnerabilities with VAddy.

In this article, we will explain the following procedure:

git push

Run unit tests

Deploy code to staging

Run VAddy tests

Deploy code to production

If the unit tests fail, the following steps in the process are skipped. Likewise, if VAddy’s tests fail, code will not be deployed to production. By regularly running unit tests and scanning your web application for vulnerabilities, you can prevent buggy code from being deployed to production.

Prerequisites

Because VAddy sends HTTP requests over the Internet when it scans for vulnerabilities, your test server must allow external connections. (If you have already set up a staging server, you should be able to use that.)

Unfortunately, Codeship instances do not allow external access and thus do not constitute a complete testing setup—yet. This would be very convenient and will consequently be supported in the future.

Step 1

Register the server that you would like VAddy to test. You will be issued a Web API key once VAddy is ready to scan your server. For more details on issuing web API keys, see the VAddy Quickstart Guide.

Register VAddy’s API keys and other environment variables from the Environment section of Codeship’s Project Settings screen.

Specifically, register the following three environment variables.

VADDY_TOKEN: Your web API key.

VADDY_HOST: The fully qualified domain name (FQDN) of the server that you have registered with VAddy for testing.

VADDY_USER: Your VAddy login ID.

Step 2

Add a new test pipeline with the following commands from the Test section of Codeship’s Project Settings screen. We have also provided a Gist with these sample settings.  https://gist.github.com/ichikaway/e20450fe1910f760c613

./unit-test.sh ./deploy-staging.sh git clone [email protected]:vaddy/vaddy-api-ruby.git cd ./vaddy-api-ruby ruby vaddy.rb && cd ../ ./deploy-production.sh

The test pipeline above runs unit tests with unit-test.sh, deploys code to staging with deploy-staging.sh, sets up VAddy’s Ruby client tool with git clone, runs a VAddy scan with vaddy.rb, and finally—if all of the tests pass—deploys code to production with deploy-production.sh.

Define unit-test.sh, deploy-staging.sh, and deploy-production.sh as appropriate for your project. Though the test pipeline above deploys code to production with its own shell script (deploy-production.sh), you may find Codeship’s deployment pipelines more convenient to use.

Smoke Test

Run git push. If none of VAddy’s tests fail, processing will continue and deploy-production.sh will be run.

If VAddy finds even a single vulnerability, processing will stop and deploy-production.sh will not be run.

Simple Chat Integrations

The Notification section of Codeship’s Project Settings screen shows a list of integrations with other services. Both Hipchat and Slack have very helpful integrations; we’re going to briefly explain how to use Hipchat’s here.

Enable the Hipchat integration with your Hipchat notification token and room name, then push code to your repository. If VAddy discovers a vulnerability while scanning your application, the Codeship tests will fail and your HipChat room will receive a notification with the error. Once you’ve resolved the problem and re-run the tests, your Hipchat room will receive a notification indicating that the tests passed successfully.

Summary

As we have shown in this article, it’s easy to integrate with VAddy using its (Ruby) client. Though we already released a VAddy Jenkins plugin, we also implemented a Ruby tool that uses the VAddy API to support Codeship and other recent continuous integration service providers.

We have released VAddy’s client tool under an open-source license, so you should be able to use it with services other than Codeship. In fact, we have already provided instructions for testing with CircleCI.

We have also published our Web API specifications, allowing you to build your own client tools for your projects.

VAddy is a service that works together with your CI tools to implement continuous security tests. We invite you to take it for a spin; our free plan doesn’t even limit the number of tests you can run!

Developers! Looking for a free and simple hosted Continuous Delivery service?

Search no more! Try the simplest Continuous Delivery service out there with Codeship.

http://bit.ly/simplecontinuousdelivery

tumblr 편집기는 참 쓰기 힘들다. -_-)a 

의도

 세상이 좋아져서 배포하는 방법도 많고 사용하기 좋은 사이트/도구들도 많아졌기 때문에 정답은 없지만, codeship 블로그에서 소개한 방법으로 테스트 해 보니 commit 한 번으로 빌드/테스트/배포 후 public website로 접근이 가능해져서 개인 프로젝트에 적용해보기로 하였다. 실제로는 개인 프로젝트 뿐만 아니라 회사 내에서 프로젝틀 할 때도 상용 직전의 배포 전까지 사용해도 될 듯 싶었다. 특히 1인 개발인 경우 개발 자체에만 집중하기에도 부족하기 때문에 빌드/배포 관련해서는 미리 세팅해두고 싶었다.

Bitbucket - Mercurial/Git 버전 관리 시스템을 사용하는 웹 기반 호스팅 서비스이다. - Bitbucket은 원래 독립 프로젝트였으나 2010년 9월에 Atlassian 에 인수되었다. - Collaborative revision control을 표방하고 있다. - 개인 사용자에 대해 private repository 를 5개까지 사용할 수 있다. 그래서 github쓰다가 가끔 bitbucket도 쓰고 그런다. - 더 자세한 설명은 http://en.wikipedia.org/wiki/Bitbucket Heroku - 클라우드 애플리케이션 플랫폼이며 웹서비스를 빌드 배포를 제공하는 새로운 방법이다. 배포, 실행, 관리를 담당하고 Ruby, Node.js, Java, Python, Clojure, Scala를 지원한다. - 애플리케이션 개발자가 코딩하는 데에만 집중할 수 있게 도와주는 역할을 한다. 서버 관리, 배포, 운영, 스케일링 (확장) 등은 우리가 알아서 할게! 가 컨셉이다. Codeship - https://angel.co/codeship - http://mashable.com/2013/10/01/hot-european-startups/ - https://devcenter.heroku.com/articles/codeship - Heroku에서도 addon으로 제공하고 있으며, CLI(Command Line Interface/Client)를 이용하여 실행 가능하다. - codeship에서는 Continuous Deployment를 여러 언어에 걸쳐 제공하고 있다. 방법

.... 이미지 첨부하다가 속 터질거 같아서 evernote링크를 공유하니 여기를 보시길. -_-)

https://www.evernote.com/shard/s216/sh/2edf6898-f2af-4d77-9f90-e3fd83856aeb/d1b02ed82c97b4db64710a048b27b8aa

결론 런칭 직전 테스트/빌드 테스트 및 배포 환경까지 마련하여 베타 테스트까지는 이 방식으로 해도 괜찮겠다 싶었다. 무엇보다 커밋 한방에 public server 로 반영되니 수정사항 체크 및 테스트도 할 수 있어서 더욱더 견고한 소프트웨어를 만들 수 있고, 이 방식을 한번 세팅해놓으면 개발자는 정말 개발에만 집중하면 되겠다 싶었다. 마음만 먹으면 빌드/배포/테스트 환경 구축을 만들 수 있는 방법은 얼마든지 있으니, 이제 서비스를 만들러 가자~ 원문 http://blog.codeship.io/2013/10/02/how-to-deploy-a-ruby-on-rails-app-from-bitbucket-to-heroku.html 원제: How to depoy a ruby on rails app from bitbucket to heroku troubleshooting      1. heroku에서는 sqlite3을 지원하지 않으므로 DB 를 PostgreSQL로 변경한다.      http://robdodson.me/blog/2012/04/27/how-to-setup-postgresql-for-rails-and-heroku/      2. Rails 4 를 이용하기 위해선 아래 업그레이드 가이드에 따라야 한다. asset에 접근하기 위해 아래 gem 추가 설치.

    gem 'rails_12factor', group: :production

    1번에서 언급했듯이, PostgreSQL gem 설치.

    gem'pg'        

    Rails 4버전으로 업그레이드 한 후 아래 커맨드를 build 스크립트에 추가.

    rake rails:update:bin https://devcenter.heroku.com/articles/rails4

여담 1. 아, 물론 bitbucket-heroku만 연결할 순 있지만 Heroku CLI를 사용해야 하기 때문에 조금 더 번거로울 수 있겠다. 

https://toolbelt.heroku.com/

Using CodeShip to run tests and deploy php application code has been a delightful experience. The CodeShip team has created a great service and the few times that we've had questions they were promptly available to help out.

By default, CodeShip builds any branch in your repository when a commit is made to your remote repository, which is perfect for testing master, feature and fix branches with ease. CodeShip deploys our master branch when the test suite passes, and if something fails there are several notification options: email, hipchat, campfire, grove... etc.

We have a few tips for Laravel 4 users interested in using CodeShip.

Setup Commands:

Use phpenv local 5.4 to set the php environment. This is helpful if you need to specify a specific php version.

Try composer install --prefer-source if you experience any composer install issues.

Test Commands:

Run vendor/bin/phpunit if you've specified phpunit as a project dependency in your composer file.

To start the Laravel server in the background use:

nohup bash -c "php artisan serve &" && sleep 3

Run vendor/bin/behat to execute your acceptance tests. Make sure you run Laravel serve in the background so you have a local live site to interact with.

Deploy

We configured the simple deploy process to run the built-in Heroku deploy script and then a custom script after. The custom script executes the following code on Heroku:

composer install --prefer-source php artisan optimize

TDD: Designing code with RSpec @clemenshelm (via @Codeship)