GitHubにプロジェクトのロードマップ追跡管理を統合したZenHub

GitHubを統合した人気の高いプロジェクト管理ツールであるZenHubは米国時間11月6日、新しいプロダクトとしてRoadmapsを発表した。その名のとおりロードマップを作成して管理する機能で、チームがプロジェクトを前もって良質に計画し、そのステータスを視覚化する。そしてそのすべてを、GitHubの中から操作できる。

ZenHubの共同創業者であるAaron Upright(アーロン・アップライト)氏は「これはまったく新しいカテゴリーのプロダクトだから超エキサイティングだった。従来のように、ソフトウェアの開発チームが将来のことを考えながらプロジェクトを管理するのではなくて、具体的にいつ何をするかを前もって計画するんだ。これをZenHubを進化させる機会として生かし、プロダクトのロードマッピングという新しい世界への入り口を提供したい」と語る。

このプロダクトそのものは、かなり単純明快だ。デフォルトでは、チームがすでに定義している既存のプロジェクトや作品を対象とし、タイムラインに沿ってそれらを視覚化する。そこには、まだ残っている未解決の問題に関するデータも含める。このツールの現在のバージョンはかなり基本的なものしかないが、将来はブロッキングなどの高度な機能も入れる予定だ。アップライト氏が言ったように、目標がチームの計画を助けることだから現状で十分役に立つが、ZenHubが望むのは「プロジェクトのステートの概要が30000フィートと超長くても、GitHubやJiraの中で個々の問題をクリックしまくらなくてもいい」という理想的な計画管理の状態だ。

アップライト氏によると、既存のソリューションはチームが本当に必要とすることに対応していない。彼によると「しかもそれらのツールは高すぎて10名から20数名程度のチームには手が出せない。またロードマップを追跡するのにExcelのファイルやGoogleのスプレッドシートを使っているところが多い。スプレッドシートは、その毎日毎時間のアップデートが大変で、それ専門のフルタイムの人間を必要とする」とのこと。

手ごろな価格のツールでは、そのツールとGitHubの間で同期できないので、肝心のGitHubの最新状態を維持できない。ZenHubはGitHubの中にいるから、そんな問題はそもそもない。

ZenHub Roadmapsはすでにすべてのユーザーが利用できる。

[原文へ]

(翻訳:iwatani、a.k.a. hiwa

ZenHubのWorkspacesはGitHubのリポジトリに複数のチーム別ワークスペースを作れる

GitHub用のプロジェクト管理ツールZenHubは、米国時間5月21日、そのサービスをチームで使いやすくするための機能としてWorkspacesのローンチを発表した。それはZenHubのサービスをチームのニーズに合わせてカスタマイズでき、それでも仕事の基盤としてはGitHubを使用するというものだ。

Workspacesはその名のように、チームがGitHubのリポジトリの中に複数のワークスペースを作れる(ZenHubはそのためにChromeのエクステンションを使う)。それによって、あるデベロッパーチームは、すべての問題の詳細なビューを得られ、そのほかのチームは自分たちに関係のあるものだけが見える。このことによってさまざまなチームが、ScrumやKanbanなどなど、それぞれ独自のワークスタイルを採用できる。

ZenHubのファウンダーでCEOのAaron Upright氏はこう語る。「この機能によって各チームが独自の方法で仕事ができ、そのやり方に応じた独自のユニークなワークフローを作れる。例えば、フロントエンドのチームはGitHubの彼ら独自の問題を抱えていて、それらはKanbanスタイルのワークフローになるだろう。またバックエンドのチームなら、独自のScrumスタイルのワークフローになるかもしれない」。

問題は全チームで共有され、どのチームが今何をやってるかもわかる。つまり、社内の透明性が確保される。

画像クレジット: masahiro Makino/Getty Images

[原文へ]

(翻訳:iwatani、a.k.a. hiwa

GitHubがパッケージレジストリを提供、主要なパッケージマネージャーと互換性あり

GitHubは米国時間5月10日、GitHub Package Registryを非公開ベータでローンチした。このパッケージ管理サービスによりデベロッパーは、ソースコードと並んでパッケージをパブリックまたはプライベートで発行できる。

ただしそれはnpmやRubyGemsなどのツールと競合するものではない。GitHubのパッケージレジストリサービスはこれらのツールと互換性があり、デベロッパーは自分のパッケージを、コードのときと同じGitHubのインターフェイスを使って発行したり見つけたりできる。このサービスは現在、JavaScript(npm)、Java(Maven)、Ruby(RubyGems)、.NET(NuGet)、およびDockerイメージと互換性があり、他の言語やツールも今後サポートされる。

GitHubのプロダクト管理部長Simina Pasat氏はこう語る。「GitHub Package Registryは広く使われているさまざまなパッケージ管理クライアントと互換性があるので、自分が選んだツールでパッケージを発行できる。タイプの異なる複数のパッケージを、ひとつのレポジトリーに収めることもできる。そしてウェブフックやGitHub Actionsを利用すれば、パッケージの発行と発行後のワークフローを完全にカスタマイズできる」。

企業は社員たちに単一の認証情報を提供して、彼らのコードとパッケージの両方を管理させられる。そしてこの新しい機能により、承認済みのパッケージセットを容易に作れる。また、利用統計をダウンロードでき、GitHub上のパッケージ操作の完全な履歴にもアクセスできる。

オープンソースのパッケージの多くが、すでにGitHubを使ってコードを開発し、その後それをパブリックなレジストリへ発行している。GitHubの主張によると、そんなデベロッパーたちもこれからはGitHub Package Registryを使って、リリース前のバージョンを発表できる。

また、すでにGitHubを利用してプライベートなリポジトリをホストしているデベロッパーも少なくない。要するに、パッケージとコードは同じ場所にあったほうが便利だ。GitHubが今回行ったことは、そのような慣行を公式化してひとつのプロダクトに仕立てたものとも言える。

[原文へ]

(翻訳:iwatani、a.k.a. hiwa

Microsoftの$7.5BのGitHub買収計画にEUの規制当局が青信号を点灯

Microsoftが計画していた、Gitを利用するコード共有コラボレーションサービスGitHubの買収を、欧州連合(European Union, EU)の規制当局が無条件で承認した。

この巨大ソフトウェア企業がGitHubの買収意思を発表したのは6月で、同社の株式で75億ドルを支払う、とされた。そして当時同社は、“GitHubはそのデベロッパーファーストの精神を維持し、独立した事業活動により、すべての業界のすべてのデベロッパーにオープンなプラットホームを提供する”、と誓った。

EUの執行機関欧州委員会(European Commission, EC)が今日、その計画を承認し、その査定が、関連市場における競争を阻害しないと結論した、と述べた。この併合後の企業実体の方がむしろ、継続的に“厳しい競争”に直面するであろう、と。

ECはとくに、Microsoftには自社のdevopsツールやクラウドサービスをGitHubに統合してサードパーティのツールやサービスの統合を制限する能力や誘因はない、と言っている。

委員会は、MicrosoftにはGitHubのオープン性を損なう動機はない、とも結論している。そして、そのようないかなる試みもデベロッパーにとっての価値を減損させるだろう、とも言っている。委員会の判断では、そのようなときデベロッパーは他のプラットホームに切り替える意思と能力を持っているだろう、という。

Microsoftの前の発言では、同社は買収の完了を年内と予想している。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa

GitHubがJira Software Cloudの統合を改良、パフォーマンスとユーザー体験をアップ

AtlassianのJiraは、多くの企業で、大きなソフトウェアプロジェクトを管理するためのスタンダードになっている。しかしそれらの企業の多くがソースコードのリポジトリとしてはGitHubを利用しており、JiraとGitHubを統合する公式な方法も、かなり前からある。しかしその古いやり方は、遅くて、能力も限られ、今多くの企業がGitHubで管理しているような大きなコードベースを扱うには、向いていないことが多かった。

しかしMicrosoftに買収されたあとでもGitHubは、オープンソースのエコシステムにコミットしていることを証明するかのように、今日(米国時間10/4)同社は、二つの製品の改良された統合を発表した。

GitHubのエコシステムエンジニアリング担当ディレクターKyle Daigleは、こう語る: “Jiraに関してAtlassianと協働することは、われわれにとってきわめて重要だった。われわれの顧客であるデベロッパーには、彼らが使っているこのオープンなプラットホーム〔GitHub〕から最良の体験を確実に得てほしいからだ。彼らが今、ほかにどんなツールを使っていようともね”。

そこで二か月前にGitHubのチームは、Jiraとの独自の統合を、完全にゼロから再構築することに決めた。そして今後は、それをメンテナンスし改良していくことにした。Daigleが言ってるように、改良の重点はパフォーマンスとユーザー体験の向上に置かれた。

この新しい統合により、JiraのIssue(課題)に結びついているすべてのプルリクエストやコミット、ブランチなどをGitHubから容易に見ることができる。GitHubからの情報に基づいてIssuesを検索できる。そしてまた、開発ワークのステータスをJiraの中でも見ることができる。GitHubで行った変更がJiraのアップデートもトリガーするので、そのデータはどんなときでもアップツーデートに保たれる。

いわゆるJira DVCSコネクターを利用するJiraとの古い統合は非推奨になり、GitHubは、数週間以内にアップグレードするよう、既存のユーザーへの告知を開始する。新しい統合はGitHubのアプリケーションなので、このプラットホームのセキュリティ機能をすべて装備している。

画像クレジット: TechCrunch

[原文へ]
(翻訳:iwatani(a.k.a. hiwa

GitHub Enterpriseと〜Business Cloudのユーザーがオープンソースのリポジトリにアクセスできる

Microsoftが最近買収したコードホスティングサービスGitHubが今日(米国時間7/13)ローンチした新しい機能により、企業ユーザーがこのサービス上のパブリックなリポジトリに容易にアクセスできるようになった。

GitHubの企業ユーザー向けバージョン、GitHubがホストするGitHub Business Cloudと、企業自身がホストするGitHub Enterpriseのユーザーは従来、このサービスの上に何百万もあるパブリックでオープンソースなリポジトリに直接アクセスできなかった。それが今回変わり、企業ユーザーは彼らのファイヤーウォールを越えてGitHubのコミュニティのすべてに直接関与し、コラボレーションできることになった。

そのためにGitHubが今回企業ユーザーとエンタープライズユーザーに提供することになった総合検索機能は、内部のリポジトリだけだなくオープンソースのリポジトリも検索できる。

最新のEnterpriseに導入されたそのほかの機能として、コードの変化を調べるときホワイトスペースを無視する指定ができる。また、コードの変更に対して複数のレビュワーの関与を必須とする指定や、サポートチケットの自動化などもある。アップデートの全貌は、ここで分かる。

Microsoftによる買収はそれほど意外でもなかったし、しかもまだ完了していないが、でもMicrosoftと、GitHubを拠り所とするオープンソースコミュニティという無理婚は、今だに議論を喚んでいる。両者はこれまで、目を合わせたことすらなかったのだ。でもぼく個人の考えとしては、それほど心配する必要はないし、現時点ではすでに一件落着して、Microsoftがこのサービスをこれからどうするのか、みんなが見守っている段階だと思う。

関連記事: MicrosoftがGitHubを75億ドルで買収(未訳)
    : MicrosoftがGitHubの運営の独立性を約束      

[原文へ]
(翻訳:iwatani(a.k.a. hiwa

GitLabがGVのリードするシリーズCで$20Mを調達、ソフトウェア開発〜リリースの総合ソリューションを目指す

デベロッパーのためのコラボレーションとDevOpsのプラットホームGitLabは現在、10万あまりの企業が利用している。同社は今日(米国時間10/9)、GV(元Google Ventures)がリードするシリーズCのラウンドにより2000万ドルを調達したことを発表した。これでGitLabの総調達額は4550万ドルあまりとなる。

新たな資金調達に加えて同社は今日、WordPressの協同ファウンダーMatt Mullenwegが同社の取締役会に加わったことを発表した。

GitLabは、その名が示すように、gitをベースとし、デベロッパーがコードのリポジトリーをセルフホスティングしていくためのオープンソースのツールだ。しかし2014年のローンチ以来同社は、そのほかのDevOps向けサービスをいくつも新設してきた。それらの中にはワークフローツールがいくつかあり、またコードのレビューやリリースを容易にできるためや、アプリケーションのモニタリングのための機能すらある。

そこで同社は、自己のミッションを次のように定義している: “現代のソフトウェアデベロッパーのためのシームレスで総合的なプロダクトを開発し、またKubernetesによるソフトウェア開発のためのアプリケーションになること”

そう。今やGitLabですら、Kubernetesというゲームに深く関わりたいのだ。

GVのゼネラルパートナーDave Munichielloは、今日の声明文の中で次のように述べている: “Fortune 500社は今、互いに競ってワールドクラスのソフトウェア開発組織を作ろうとしており、またそれらに、世界最大のテクノロジー企業なみのスピードと生産性とクォリティを持たせようとしている。これらの組織は高品質で大規模なコードを作るべく努力しているので、最高クラスのツールとプラットホームを必要とする。GitLabのプラットホームは、コラボレーションとオートメーションを強調することにより開発プロセスを加速する。GitLabのハイブリッドでマルチクラウドのソリューションはデベロッパーに好まれており、その分野で巨大なファン層を形成している”。

GitLabの現在のユーザーには、Ticketmaster, ING, NASDAQ, Sony, Intelなどもいる。

新たな資金の使途について同社は、“ソフトウェアのパッケージングとリリース方式と構成とモニタリングに関して新たな機能性を加えたい”、と言っている。

同社の競合サービスはGitHubやAtlassianのBitBucketなどだが、GitLabによると、セルフホスティング型のgit市場では同社が2/3のシェアを占めるそうだ。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))

大量の既存コードで訓練されたAIがプログラマーにオートコンプリートを提案するCodota、Khoslaが$2Mを投資

GitHubを使うようになってデベロッパーのワークフローは抜本的に変わった。コードをアクセスしやすいプラットホーム上に集積することによって、プログラミングのやり方が急速に変わった。そんな状況を受けてイスラエルのCodotaは、これまで無視されることの多かったデベロッパーコミュニティのワークフローをさらに最適化したい、と考えている…マシンインテリジェンスを利用して。同社の自動補完(オートコンプリート)機能を使えば、良質なコードを短時間で書けるようになる。同社はこのほど、Khosla Venturesから200万ドルのシード資金を獲得したことを発表した。

CodotaはEclipsのようなIDEと併用して、そのインテリジェントなコード補完機能を利用する。それは、「あなたが意図するものはこれではないですか?」と短い例示をくれるのではなく、もっと大きなコード集合をリコメンドできる。

協同ファウンダーのDror WeissとEran Yahavは、GitHubやStackOverflowにあるオープンソースのコードを利用してCodotaを作った。その公開コードのすべてを機械学習のモデルに食べさせて、コードブロック全体の高いレベルの意味を認識できるようにした。

テルアビブの本社におけるCodotaのチーム

プログラミング言語は一般言語と同じ構造を共有している部分が大きい。たとえば、語の限りなく多様な並べ方によって、考えや感情を表現する。また、同じコマンドでもコード中でいろんなやり方で表現できる。だからCodotaにとっては、コードがやってることに関する大局的な理解がとても重要だ。コードのミクロな像ではなく、マクロな像を理解することが重要なのだ。

もちろん、自然言語とコードが似ているのは、あるところまでだ。Codotaのチームが説明してくれたところによると、自然言語処理では、意味は語の近辺の複数の語を見て判断する。それに比べるとプログラムはもっと構造性があり、語がどこにあるかによって語の意味が違うことは少ない。だからCodotaはテキストで訓練するだけでなく、プログラムの動作/振る舞いにもフォーカスした。

Codotaを使うとスピードと正確さが向上するだけでなく、Codota自身の発見や教育にも助けられる。Codotaは何百万ものAPIの実装で訓練されているから、ベストプラクティスをデベロッパーに提示できる。IDEの横にCodotaを開いておくと、コード中のおかしい箇所を高輝度表示し、モアベターな代案を示す。その教えは、ライブラリの原作者のコードから直接引用したものが多い。

同社の収益源は、Codotaの利用を、そしてもちろん自分のコードを、社外秘プライベートにしておきたい企業からの使用料だ。今、対応言語はJavaだけだが、言語は今後すこしずつ増やしていく。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))

MicrosoftはWindowsの開発にGitを使う、そのための仮想ファイルシステムGVFSをすでに開発済み

Microsoftは今日(米国時間5/24)、これからは同社のエンジニアのほとんど全員が、バージョンコントロールシステムGitを使ってWindowsオペレーティングシステムを開発していく、と発表した。WindowsのGitリポジトリには約350万のファイルがあり、それらをGitにチェックインするとしたら、その重さは約300GBになる。しかしながらGitはそんなサイズのプロジェクト向けには作られていないので、MicrosoftはGit Virtual File System(GVFS)というものを作って、Gitのもっともシンプルなコマンドでも完了まで数時間待つということなく、Gitを使う利点を得られるようにした〔秘かにローカルマシン上ですべての操作を行う〕。

そのGit Virtual File SystemのコードはGitHub上でMITライセンスにより提供され、今後のコミュニティからのコントリビューションを歓迎している。

Gitへの移行には、約3か月を要した。それまでMicrosoftは、Source Depotを使ってWindowsのコードを管理し、それ以外の小さなコードベースを抱えるグループは前からずっとTeam Foundation Serverを使っていた。私の理解では、Source DepotはPerforceプラットホームのMicrosoftによるフォークであり、同社の今日の発表ではWindowsのコードは最初、40あまりのデポに分散していた。

最近の3か月でMicrosoftは、Windowsのデベロッパーの一部をGitのリポジトリへ移してシステムをテストしていた。それから3月には、Windows OneCoreチームの2000名のエンジニア全員にGitを展開した。今日では、Windowsチームのほぼ4000名のエンジニアのうち約3500名が、Gitへ移行している。

なお、Microsoftによると同社は、Git Virtual File System(GVFS)のための、Gitのプロキシソリューションを構築して、世界中に分散しているチームには避けられない帯域の問題を管理している。

さらに今日のMicrosoftの発表によると、AtlassianなどいくつかのGitベンダーがすでにそれをサポート、またTower、GitKrackenなどはサポートを準備中である。GVFSをテストするためには、MicrosoftのVisual Studio Team Services(VSTS)上にレポジトリを作るとよい(そのためにはVSTSのアカウントが必要)。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))

GitHubがプロジェクト管理ツールを内蔵へ、そして公式の多面的なレビュー過程をサポート

Workers install a billboard for GitHub Inc. in San Francisco, California, U.S., on Tuesday, Nov. 11, 2014. GitHub, which provides open-source code hosting services and has raised more than $100 million from investors, is among tech startups boosting demand for billboard space around Silicon Valley. Photographer: David Paul Morris/Bloomberg via Getty Images

GitをベースとするコードホスティングサービスGitHubは今日(米国時間9/14)、サンフランシスコでデベロッパーカンファレンスUniverseをやっている。年に一回の大会は新しい機能を発表するのにふさわしい機会だが、今回同社はそれを、“このプラットホームのこれまでで最大のアップデート”と呼んでいる。それらがどれだけ重要かは、各人のGitHubの使い方にもよるのだが。

チームで仕事をしている人にとっては、レビューの導入が最大のニュースだろう。これからはデベロッパーやメンテナーが、すべてのプルリクエストを公式に承認したり、変更をリクエストしたりできる。またレビューのサマリ(要約)を残したり、コメントをモデレート(司会調停)できる。ただし公式のレビューがなくても、インラインのコメントを残すことはできる。

7fb44b30-7976-11e6-9674-8a32a92506ff

GitHubのCEOで協同ファウンダーのChris Wanstrathが、今日の発表声明で言っている、“これによって、一行のコードに関して複数の会話をサポートでき、個々のフィードバックループが明瞭になり、会話の質も上がり、良質なコードレビューが可能になる。しかしコードレビューは今後さらに、もっと敏速かつフレンドリーなものにしていきたい。今すでにこの機能の改良に取り組んでおり、その中には同僚などにレビューをリクエストする機能もある”。

また今回のアップデートでGitHubは、単なるコードを超えて、簡単な「かんばんボード」のようなプロジェクト管理機能を加えた。これまでもGitHubはさまざまなプロジェクト管理ツールの統合をサポートしていたが、これからはプルリクエストと一緒にカードを動かしたり、カラムのあいだに“やってます”、“やりました”、“できません”などなどの注記を入れられる。Trelloなどのように、カードをドラッグ&ドロップで別のカラムへ移動できる。

6f8a5a1a-7976-11e6-8708-10e6aeb49251

今日のアップデートではさらに、GitHubのAPIが改良されて、たとえば、サードパーティのサービスが自分のサービスをGitHubに容易に統合できるようになった。また、新しい機能やAPIは、一般公開の前に“試用サービス”が提供される。

そしてエンタープライズユーザーは、ひとつのアカウント上のすべてのメンバーに二要素認証を強制できる。SAMLベースのシングルサインオンもサポートする、と言っているが、その日程は明言されなかった。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))

コンテンツ・アドレッサブルで多バージョン分散データベースNomsのAttic Labsが$8.1Mを調達

1-lsdbfqbeg_rcgnidp40dia-1

サンフランシスコのAttic Labsが今日(米国時間8/2)立ち上げたNomsは、新しい分散データベースで、その‘新しさ’はGit, Camlistore, ipfs, bupなどからヒントを得ている。同社の今日の発表では、GreylockがリードするシリーズAで810万ドルを調達し、Nomsなどのプロジェクトの継続が可能になった。Harrison Metalなどのエンジェル投資家たちも、このラウンドに参加した。

Attic Labsが初耳の人でも、ほとんどの人が、ここのチームが関わったプロジェクトのどれかを、使ったことがあるはずだ。たとえば協同ファウンダーのAaron BoodmanはGreasemonkeyの作者だし、Google Chromeの開発リーダーでもあった。もう一人の協同ファウンダーRafael WeinsteinもChromeの開発(等々)に関わり、チームのほかのメンバーたちも、Chrome、Chrome OS、ECMAScript(JavaScriptのスタンダード)などで仕事をしている。

では、Nomsは、これまでのデータベースとどこが違うのか? チームが主張するのは、今日のデータベースはその多くが、“データを単一時点の存在”と捉えている。たとえばある欄がアップデートされると、アップデートされた時点の値がその欄の値に(次にアップデートされるまで)なり、前の値を知ることは困難である。今のデータベースを分散化することは可能でも、利用する側にとってそれは単なる単一のデータ集合であり、分散にユーザーレベル、アプリケーションレベルの意味は何もない。

そこでBoodmanが今日の発表声明で書いているのは、Nomsはたぶん、Gitと比較すると分かりやすいだろう、ということだ。GitのようにNomsでもユーザーはデータをレプリケート(複製)でき、複数のマシンの上でオフラインでエディットし、それらのエディットを再びシンクする(BoodmanとWeinsteinはAvantGoなどのシンクサービスの仕事をしたこともある)。Nomsでは、ヴァージョニングとエディットが破壊的でない〔前のバージョン、前のエディットが消えない〕。ただしGitと違うのは、保存するのが定型データだけで、テキストファイルは保存しない。主に、非常に大きなデータ集合をサポートすることが目的だ。

そのため、Nomsはとくに、大量のデータをインポートする業務に向いている(自動的に重複エントリを一つにする)。また、複数のソースからのデータを組み合わせ結びつけるタスクにも合う(データの変形が簡単にできる)。そしていちばん得意なのは、そんなユースケースで必ず必要になる、大きなデータセットのシンクだ。

Boodmanは次のように書いている: “Gitがソフトウェアの世界をほとんど一晩で席巻してしまったのは、分散が本質であるためにソースコードが複数のコンピューターや組織、そして人びとのあいだを、とてもなめらかに移動し、それによって、すごく充実したコラボレーションが可能だからだ。世界は、データをなめらかに共有し、密なコラボレーションのできる方法を必要としている、と思う。それを実現する自然で必然的な方法は、コンテンツでアドレシングできる(content-addressed)〔日本語Wiki〕、非集中型で、シンク能力のあるデータベースだ”。

今日の投資の結果として、GreylockのJerry ChenがAttic Labsの取締役会に加わる。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))

AtlassianがBitbucket Cloudを利用するデベロッパーのための継続的デリバリサービスBitbucket Pipelinesをローンチ

build-statuses-next-to-commits

Atlassianが今週、うまいアブサンを飲ませる、ぼくのお気に入りのバーの近くで、例年のデベロッパーカンファレンスをやっている。キーノートで数々の新製品やアップデートが発表されたが、どれも、デベロッパーの人生をすこし楽にしてくれる(協力的にもしてくれる)ものばかりだ。

AtlassianがBitbucket Pipelinesをローンチ

新しいツールでいちばん重要なのが、Bitbucket Pipelinesだろう。Atlassianは最近、同社のGit関連サービスをすべてBitbucketの名の下(もと)に統一し、そしてPipelinesのベータバージョンのローンチにより、AtlassianがホストするBitbucket Cloudサービスに継続的デリバリサービスが導入されることになる。そうなるとデベロッパーは、コードを自分たちのBitbucketリポジトリにプッシュしアップデートしていくビルドとデプロイのワークフローを容易に自動化できる。

ベータの期間中Bitbucket Pipelineは、誰もが無料で試用できる。

これまで、AtlassianのツールはつねにWebから提供された。しかし同社は今日初めて、チームコラボレーションサービスConfluenceと、ソフトウェアチームのための同社のプロジェクト管理サービスJIRA Softwareの、ネイティブアプリケーションをローンチした。

さらに今日Atlassianは、Open API Initiativeへの参加を表明した。この、APIの形や作り方を標準化しよう、というねらいのコンソーシアムには、Apiary, Apigee, Google, IBM, Mashape, Microsoft, PayPalなどなどが参加している。

また今日ローンチされたConnect for JIRA Service Deskは、サードパーティのデベロッパーが、JIRAに埋め込めるアドオンを作れる、というサービスだ。そしてAPIのドキュメンテーションを作るための社内的なツールRADARがオープンソースになった。これは当然ながらOpen API Initiativeの仕様に従っている。

 

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))

AtlassianのBitbucket Serverがコードの検索をやっとサポート

Red Buckets in a Row

Atlassianの自己ホスト型GitバージョンコントロールサービスBitbucket Serverと、Bitbucket Data Centerに、小さいけどとても便利な新しい機能が導入されることになり、今そのプレビューをやっている。今提供されているBitbucketアーリーアクセスバージョンには、ユーザーのレポジトリ中のコードを検索する機能があるのだ。

これがあると、ちょっとしたコード片を自分のgitリポジトリに素早く見つけることができるし、コード中にメモしておいた謎のようなエラーメッセージも、どこに書いたかを正しく思い出せる。

Bitbucketのコンペティターで、同じくgitの便利ラッパー(wrapper)を提供しているGitHubやGitlabには、前からコード検索の機能がある。だから、この部分ではBitbucketはやっと追いついたと言えるが、でもBitbucketのユーザーにとっては、そんなことより、なにしろ便利だ。彼らはかなり前から、検索のサポートを要望していたのだから。

コンペティターたちと同じく、Bitbucketでも検索結果を言語やファイルの拡張子でフィルタできる。検索演算子AND, OR, NOTも使える。

同社によると、AtlassianがホストするバージョンのBitbucketではまだ検索がサポートされていない。しかしそれも、長くはないだろう。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))

AtlassianのStash Data Centerがベータを終え一般公開へ、エンタプライズ向けGitを志向

GitリポジトリツールStashを提供しているAtlassianが、エンタプライズ向けのGitラッパーとして作ったコード管理サービスStash Data Centerが、数か月の公開ベータを終えて今日(米国時間3/2)、正式にローンチした。このサービスを使うと企業はサーバのクラスタの上でGitを動かし、多数のデベロッパを支援できる。ベータ時には、最大で12000名のデベロッパをサポートしたそうだ。

Atlassianのデベロッパツール担当VP Eric Wittmanによると、Gitは4月に10歳を迎えるが、その企業利用は最近やっと始まったばかりだ。その理由は、彼によると、Gitが企業にとって難しいことだ。彼曰く、“分散バージョン管理はすばらしいが、Git自体はかなり荒削りだ。内部の細かい仕組みまで分かっていない人には、ちょっと近づきがたい”。

大企業にとって、Gitをもっと使いやすく管理しやすくするのが、StashとStash Data Centerだ。

たとえばGitをそのまま使っていると、容量の限界にぶつかり、大きなチームでは使えなくなる。デベロッパの数が多すぎると、アクセス制限やパーミッションの問題にぶつかることもある。Gitはハードウェアに対して厳しいから、チームが大きくなっても簡単にはスケールできない。Stashには当然ながら粒度の細かいパーミッションがあるし、Atlassian独自のクラスタリング技術はオーバヘッドの少ないスケーリングが可能だ。だから、Gitにこれらの特性を持たせるラッパーが必要になる。

Wittmanによると、Stashのチームの約1/3が約1年、このプロジェクトに携わった。ベータでStash Data Centerのユーザだった顧客には、AmadeusやCisco、Splunk、Blackboard、Cienaなどがいる。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa


AtlassianのGit実装系StashにそのスケールアップバージョンStash Data Centerが誕生

Atlassianにはかなり前から、Gitを核とするコード管理ソフトウェアStashがある。これまでそれは、比較的小さなチーム向けのオンプレミス・ソフトウェアだったが、今日(米国時間9/10)ローンチしたStash Data Centerによって、そのGitによるソリューションを大企業にも提供していくことになった。

これまでのStashと違ってStash Data Centerは単一のサーバではなく、クラスタの上でも動く。そのためStash Data Centerは、1万名のデベロッパチーム/グループでも容易にサポートできる。しかしユーザから見てStash Data Centerの機能、操作、使い方などは今のStashと変わらない。反応が遅くなることが減り、コンパイルははやくなり、ダウンタイムが少なくなるだろうが、毎日のワークフローはStashがStash Data Centerに変わっても何も変わらない。

Atlassianのデベロッパツール担当ゼネラルマネージャEric Wittmanによると、同社は数年間Stashをやったことによって、Gitについて多くを学んだ。中でもとくに重要なのは、企業顧客をGitに移行させるやり方だった。しかし最近では、Gitをもっと大規模に採用しようとする大企業が増えている。

Wittmanは曰く、“Gitを使うようになると、デベロッパの仕事のやり方が変わる。彼らは前よりもずっと積極的にコラボレーションするようになるが、しかし問題は、そのコラボレーションのスケーラビリティだ”。Gitへの移行とともに企業ユーザは継続的インテグレーションが開発の日常的な実践になり、したがってデベロッパがソースコード管理サーバ(Stashサーバ等)にアクセスする頻度も増す。もちろんアドミンはサーバの負荷増大に気づき、スケーラビリティが不安のタネになるだろう。

当面Atlassianの想定としては、Stash Data Centerはファイヤウォールの背後のユーザ自身のクラスタにインストールされるだろう。しかし長期的には、AWSのような公開クラウドで動かすようになるかもしれない。

Stash Data Centerの料金はユーザ数をベースとする月額制になる(Stashはライセンスの売り切りだった)。Wittmanによると、Stash Data Centerは通常のStashに比べてR&Dの原価が高いので、そういう料金制にせざるをえなかった、という。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))


Visual Studio 2013の三度目のアップデートではGitベースの開発をより優遇、Azureの統合も充実

MicrosoftVisual Studioは、だいたい二年ごとにニューバージョン、あいだにサービスパック、というパターンを守ってきたが、しかしVisual Studio 2013以降は、アップデートのペースが早くなった。そして今日Microsoftは、Visual StudioとTeam Foundation Server 2013の三度目のアップデートリリースした。前回のアップデートはVisual Studioのクロスプラットホームな開発機能の強化が中心だったが、今日のローンチはIDE本体の機能に力が向けられたようだ。

このリリースでデベロッパに喜ばれそうな機能は、CodeLensがGitのリポジトリをサポートしたことだろう(Visual Studio Ultimateのユーザの場合)。MicrosoftはこのところGitとVisual Studioの統合に邁進してきたが、これもまたその一つだ。CodeLensはIDEの中で、目の前のコードに関する情報(この関数はほかにどこで使われたか?最後にそれをエディットしたのは誰か?などなど)を見せてくれる。これまでそれは、MicrosoftのTeam Foundation Serverと一緒でないと使えなかったが、今度からはGitベースのシステムを使っているときでも、そんな情報が得られる。


Visual Studioのこの三度目のアップデートでは、診断ツールの充実も図られた。たとえば、アプリケーションのCPUとメモリ利用を追跡するツールがアップデートされた。また、すでに展開されているアプリケーションをモニタリングするための新しいツールApplication InsightsがVisual Studio本体に組み込まれ、ユーザが今何をやっているかを見ながらコードの問題を診断できるようになった。

Azureの機能…Push Notifications(プッシュ通知)やAzure Mobile Serviceなどを使うためのツールも提供される。たとえばプッシュ通知のアップデートにより、Visual Studioの中からデバイスの登録を管理できるようになった。これはとくに、開発フェーズにおいて重宝するだろう。

プロジェクトでAzure Mobile Serviceを利用することも、容易になった。そのほかのAzure関連のアップデートとしては、32ビットの仮想マシンをリモートでデバッグする、ストレージのアクティビティログをチェックする、Azure上のストレージをリードオンリーに設定するなどを、アップデートされたAzure SDKによりVisual Studioからできるようになった。

例によって、今回のアップデートも機能山盛りで、新たなdevopsツール、ASP.NETのアップデート、ハイブリッドアプリケーションを書くデベロッパのための新機能、などなどもある。機能の完全なリストは、ここにある。

おっと、それから、Visual Studio 2013ではすべてのメニューが大文字なのが嫌だった人、あなたの苦悩もやっと終わりだ。この三度目のアップデートでは、メニューにタイトル書体を使えるようになった。人によっては、これだけでもアップデートする十分な動機になるだろう。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))