タグ

developmentに関するhdkINO33のブックマーク (11)

  • Ansibleのテスト事情 | DevelopersIO

    テストしてますか? 渡辺です。「進捗どうですか?」のダメージは計り知れないことはご存じかと思いますが、「テストしてますか?」のダメージも侮れません。 前者はほぼ全てのエンジニアに有効なアタックですが、後者はそれなりの経験を積んだエンジニアにしか有効でない点は異なりますね...。 さて、Ansibleを運用してくるとなれば、どうしても「どうやってテストをすべきか?」という問題にぶち当たります。 そこで、Ansibleを運用する中でのテストの考え方についてまとめておきます。 Ansibleの考え方とテスト Ansibleのような宣言型の構成管理ツールが登場するまで、サーバ構築の自動化といえばセットアップスクリプトの実行でした(自動化されていない場合は、ひとつひとつコマンドを打ち込んでいたでしょう)。 例えば、CloudFormationのcfn-initのUserDataでは次のようなセットア

    Ansibleのテスト事情 | DevelopersIO
    hdkINO33
    hdkINO33 2016/06/24
    "「不安」を感じるとき、あなたはテストすべき"
  • Clojure記事紹介百日修行(1):「MetabaseがPythonからClojureに移行した理由」 - 本当は怖いHPC

    medium.com Metabaseというオープンソースのソフトウェアが、PythonからClojureへ移行した際に、Clojureを言語として選定した理由が 記述されていました。要約して紹介します Pythonで書かれたものから移行した理由 Metabaseの前進となった社内ソフトウェアは、PythonとDjangoAngularを用いた物だったそうです。 しかし、 WSGIのリクエストモデルが、MetabaseのAPIのモデルと合わない MySQL、Postgresqlのドライバが要コンパイルだったためデプロイ・サポートが面倒 ソフトウェア全体を構成する部品が多く、いろんなところが不安定だった。具体的には、Docker + nginx + uWSGI + Django + compiled drivers + search indexing (whoosh) processes

    Clojure記事紹介百日修行(1):「MetabaseがPythonからClojureに移行した理由」 - 本当は怖いHPC
  • チームで学ぶ - 未来のいつか/hyoshiokの日記

    PBL(Project Based Learning)の授業を持っていて、その教員が集まってあーだこーだという会に参加している。PBLという手法は必ずしも教員にとっても経験豊富なものではないので学生の指導方法とかに悩みが多いので、いろいろな立場の人が集まって、あーだこーだ試行錯誤や悩みについて披露し合う。 産業技術大学院大学でのPBLはウェブアプリケーションの作り方を学ぶというもので、モダンなソフトウェア開発手法やクラウドを前提としたツールなどを利用してチームで実際にものを作る。 *1 キーワードとして、Continuous Delivery (CD), Test Automation, Continuous Integration (CI), Version Control System, Test Driven Development (TDD), Platform as a serv

    チームで学ぶ - 未来のいつか/hyoshiokの日記
    hdkINO33
    hdkINO33 2016/06/09
    "実際プレゼンにパワポはいらない。Demo or Dieだし、Done is better than perfectを実践する"
  • The Twelve-Factor App (日本語訳)

    はじめに 現代では、ソフトウェアは一般にサービスとして提供され、Webアプリケーション や Software as a Service と呼ばれる。Twelve-Factor Appは、次のようなSoftware as a Serviceを作り上げるための方法論である。 セットアップ自動化のために 宣言的な フォーマットを使い、プロジェクトに新しく加わった開発者が要する時間とコストを最小化する。 下層のOSへの 依存関係を明確化 し、実行環境間での 移植性を最大化 する。 モダンな クラウドプラットフォーム 上への デプロイ に適しており、サーバー管理やシステム管理を不要なものにする。 開発環境と番環境の 差異を最小限 にし、アジリティを最大化する 継続的デプロイ を可能にする。 ツール、アーキテクチャ、開発プラクティスを大幅に変更することなく スケールアップ できる。 Twelve-F

  • 404 Not Found|ハンズラボ株式会社

    Webページが見つかりません 可能性のある原因 ・アドレスに入力の間違いがある可能性がある。 ・リンクをクリックした場合には、リンクが古い場合があります。 アドレスを再入力するか、前のページに戻る、 またはメインのサイトに移動して必要な情報を探してください。

    404 Not Found|ハンズラボ株式会社
    hdkINO33
    hdkINO33 2016/04/22
    “あとシェルスクリプトは他の言語に比べて簡単かというと、そうでもない。”
  • 404 Not Found|ハンズラボ株式会社

    Webページが見つかりません 可能性のある原因 ・アドレスに入力の間違いがある可能性がある。 ・リンクをクリックした場合には、リンクが古い場合があります。 アドレスを再入力するか、前のページに戻る、 またはメインのサイトに移動して必要な情報を探してください。

    404 Not Found|ハンズラボ株式会社
    hdkINO33
    hdkINO33 2016/04/22
    "本当に主観ですが、シェルスクリプトとは適切な距離を持って付き合っていきたいですね。べたべたしたくない。"
  • Hashicorp Ottoを読む

    Hashicorpから2015年秋の新作が2つ登場した. Otto - HashiCorp Nomad - HashiCorp Ottoがなかなか面白そうなのでコードを追いつつ,Ottoとは何か? なぜ必要になったのか? どのように動作するのか? を簡単にまとめてみる. バージョンは 0.1.0 を対象にしている(イニシャルインプレッションである) Ottoとは何か? 公式はVagrantの後継と表現されている.が,それはローカル開発環境の構築も担っているという意味で後継であり,自分なりの言葉で表現してみると「OttoはHashicorpの各ツールを抽象化し開発環境の構築からインフラの整備,デプロイまでを一手に担うツール」である.ちなみにOttoという名前の由来はAutomationと語感が似ているからかつ元々そういう名前のbotがいたからとのこと. なぜOttoか? なぜVagrantで

  • 複数プロジェクトを抱えるチームでのデプロイ自動化

    複数プロジェクトを抱えるチームでのデプロイ自動化 1つのチームで,10以上のプロジェクト,コードベースを抱える場合にどのようにデプロイの自動化を進めたか,工夫したこと,考慮したことなどをまとめておく. デプロイツールには,Python製のfabricを採用しているが,他のツールでも同様のことはできそう.なお,fabricの基的な使い方などは既にインターネット上に良い記事がたくさんあるので書かない(最後の参考の項を見てください). fabricの選択 シェルスクリプトとCapistranoを考慮した. まず,シェルスクリプトは人によって書き方が違うため,統一が難しくメンテナンスコストも高い.また共通化も難しい. 次に,Capistranoは,裏でやってくれることが多く,学習コストも高い.プロジェクトによってはかなり特殊な環境へのデプロイも抱えているため,Capistranoの前提から外れる

    hdkINO33
    hdkINO33 2016/04/07
    "俺が通り過ぎた後には自動化されたシステムしか残らない" シビれる
  • Backlog辞めたいけど辞められないから欲しい機能を自分たちで作った | ロードバランスすだちくん

    シンジです。シンジは情シスかつセキュリティ責任者なので、Backlogを使う上ではそーゆー立ち位置で評価するのですが、BacklogってSAMLは喋られないし、管理者権限の扱いがあってないような感じだし、ISMS的にいわれるところだと管理者権限の棚卸しとかが絶望でしか無いので、クラウドっぽくAPIを活用することで乗り切ろうとしている施策の話です。 そもそもcloudpackのBacklog利用状況は お客様との案件管理に利用しているのがメインで、自分たちのタスク管理は一部になります。従って、プロジェクトが新規で発生すると「管理者権限」を持ったユーザが新規のBacklogプロジェクトを発行し、「管理者権限」を持ったユーザが、プロジェクトにユーザを追加し、などなどといえばもうお分かりかと思いますが、頻繁に発生する作業の多くに「管理者権限」が必要になるわけです。 シンジ的には管理者は少数であるべ

    Backlog辞めたいけど辞められないから欲しい機能を自分たちで作った | ロードバランスすだちくん
  • 現場から変えた“サービスの作り方” -何を作るのかではなくなぜ作るのか- #devsumi

    Developers Summit 2016 Yahoo! JAPAN Tech Conference http://event.shoeisha.jp/devsumi/20160218/tokusetsu 【18-A-2】11:05~11:50 現場から変えた”サービスの作り方” ~何を作るのかではなくなぜ作るのか~ システム統括技術支援部 開発促進部 サービス開発手法 荒瀬 中人

    現場から変えた“サービスの作り方” -何を作るのかではなくなぜ作るのか- #devsumi
  • Yahoo! Japanがアジャイル開発の採用と改善で現場から変えた“サービスの作り方”(前編)。Developers Summit 2016

    Yahoo! Japanがアジャイル開発の採用と改善で現場から変えた“サービスの作り方”(前編)。Developers Summit 2016 変化の速いビジネス環境に対応するために、多くの企業がアジャイル開発の採用を進めています。 記事では、2月18日に行われたDevelopers Summit 2016のセッション「現場から変えた”サービスの作り方” ~何を作るのかではなくなぜ作るのか~」で紹介された、Yahoo! Japanにおけるアジャイル開発の導入と実践、そして改善がどのように行われたのかについての内容を記事にしました。

    Yahoo! Japanがアジャイル開発の採用と改善で現場から変えた“サービスの作り方”(前編)。Developers Summit 2016
  • 1