API構築の基礎を学んだ。QConは、開発者コミュニティにおける知識とイノベーションの普及を促進することで、ソフトウェア開発に力を与える。実務者主導のカンファレンスであるQConは、チーム内のイノベーションに影響を与える技術チームのリーダー、アーキテクト、エンジニアリングディレクター、プロジェクトマネージャー向けにデザインされている。Sheehy氏は、人工知能ハイプ時代における責任ある開発者としてのあり方について、洞察に富んだ開会基調講演をした。Grizzanti氏が、「スタッフ・プラス」への道と、それを「科学」というより「芸術」としてとらえ、芸術を創作することとソフトウェアを創作すること、そして組織のダイナミクスに対処することの類似性について語っている。Codeを採用する:確認するべき6つの適性LCNC(ローコード/ノーコード)プラットフォームは、プログラマーだけでなくプログラマーでなくても、最小限のコーディングとワンクリックのデプロイメントで、アプリケーションソフトウェアを開発できるよう設計されている。ドラッグ&ドロップ方式のインターフェースなどを利用することで、開発・デプロイメントプロセスを簡素化し、効率的なアプリケーション開発とデプロイメントを実現する。Bartholomeus氏は昔ながらの企業における構成管理とリリース管理の実行について、DevOpsにフォーカスした4本のブログ記事を書き上げた。Niek氏はまずDevOpsの理論を紹介し、それから昔ながらの企業におけるソフトウェアデリバリー問題を分析し、最終的に、問題を解決するための具体的なDevOpsプラクティスについて説明している。Project』を読んでこのブログ記事を書いた。その動機について、彼はこう説明する。これはGene氏のお伽話とIT懐疑論者の現実との間にある穴を埋めようとするものです。Niek氏はDevOpsの理論について、協調作業というカルチャーとエンドツーエンドの理解を築きながら、自動化のための支援ツールを使うことで効率のよいプロセスを導入することだと説明した。彼はDevOps導入に対する抵抗勢力(対立する関心を守るチーム、変化と安定との間にある競合、よく見られる変化に対する抵抗運動)について分析した。した課題があるにも関わらず、彼の話のDevOpsプラクティスは特に、ソフトウェアデリバリーの複雑さ(最悪の場合、拡張性がなく、手作業の労働力を要するプロセスになる)を克服することをターゲットとしている。Niek氏は3番目のブログ投稿で、構成管理の導入について書いた。彼はそこで、ビジネス応用、変更要求、ソフトウェアコンポーネント、デプロイメント要求、リリースの間にある関係を正確に管理することの必要性について述べた。最後の投稿でNiek氏は、リリース管理の導入と前に紹介した構成管理ツールとの統合について述べた。彼の最終的な概念図は次のようになる。継続的デリバリーやゼロダウンタイムなどのさらに進んだDevOpsプラクティスには漸近的な変化が必要であり、昔ながらの企業にはまだ準備ができていないことを認めた。彼による最初のステップは企業をそう方向付けるものだ。彼は次のように述べた。従来のソフトウェアデリバリープロセスを徐々にコントロールし、可能なところを自動化して徐々にリリース頻度を高めることができれば、おそらくいつか、継続的デプロイメントへの跳躍は恐れるものではなくなるかもしれません。DevOpsプラクティスを導入するための作業は、複数の現実世界の問題を解決するのに貢献すると言って、話を締めくくった。して得られた環境は、自動化され、首尾一貫し、コントロールされ、適切に調整されたものになる。テストの領域にはやるべきことがまだまだあると彼は考えている。毎週火曜日に前週のまとめコンテンツをお送りいたします。(日本語版は不定期リリース)25万人のシニアな開発者コミュニティーにぜひご参加ください。サンプルを見るあなたのメールアドレスはこちら国を選んでください。プライバシーポリシーに従って私の個人情報を扱うことに同意します。毎週火曜日に前週のまとめコンテンツをお送りいたします。(日本語版は不定期リリース)25万人のシニアな開発者コミュニティーにぜひご参加ください。サンプルを見る様々なイノベーターとアーリーアダプターがお送りするテクノロジーの概要を見る。自分がまだ知らないことに気づいていないと知るあなたが興味のあるトピックスをいつでも最新な情報に。あなたのメールアドレスはこちら国を選んでください。プライバシーポリシーに従って私の個人情報を扱うことに同意します。Inc.プライバシーBT。