考えてみたら、まとめて書いた方がいいかもしれません。
私はすでに長い間 Coding を使用していますが、Coding は無料で使用でき、機能はすべて公開されています。開発を規範に従って行うのに適しています。以下のプレゼンテーションは、自分自身のことを話し、SaaS サービスを提供しないため、無駄話です。
バイト納品の実践#
レベルが足りないので、見ることができません。
基本情報#
元のアドレス：
- Info アドレス 2023-02-06 フロントエンド DevOps の実践
秦烁は現在、バイトダンスのフロントエンドアーキテクトとして勤務しており、DevOps の構築とフロントエンドシナリオのベストプラクティスの実施を主に担当しています。フロントエンドエンジニアリング、可視化、パフォーマンス最適化にも豊富な実践経験があります。
プレゼンテーション：バイトでの継続的な納品の実践
技術のアップグレードはビジネスの発展に欠かせません。バイトのビジネスの発展に伴い、効率化製品も複数のマイルストーンの開発を経てきました。2012 年から現在までのマイルストーン的な発展は、キーワードが「自発的」から「ライフサイクル全体」に変わったことをよく示しています。ただし、研究開発体験の向上と効率の向上を期待することは変わりません。フロントエンドの効率問題も、プラットフォーム間の連携と縦方向の能力構築の向上が急務となる時代において、ワンストップサービスが登場しました。今回の共有では、全体から詳細まで、一体化プラットフォームの解剖から多くのビジネス協力のベストプラクティスまで、自動化と可視化を中心に、バイトのフロントエンドの継続的な納品領域の実践について包括的に紹介します。
プレゼンテーションの概要：
- 背景
- 開発中の効率問題
- 効率問題の解決経路
- アーキテクチャ
- ワンストッププラットフォームの全体的なフレームワークの概要
- フロントエンドシナリオツール体系とプラットフォームの能力
- フロントエンド開発プロセスの全体的な適用
- フロントエンドシナリオの異なる解決策（概要）
- 開発プロセスの効率化（継続的インテグレーション）
自動化の探求（自動化）
- 結論と計画
- 将来のトレンドの予測
以下の情報は、info の公開情報から取得しました。
内容紹介#
主に全体的な考え方で、元の文章の内容に注釈を付けます。
アウトラインを見ると、まず背景、アーキテクチャとレイヤー、実装と指標の違い、展望について話すと予想されます。
背景#
開発効率の概念の普及。
具体的な業務タスクは、異なる立場から異なる視点で対応します。
- ビジネスレイヤー - ビジネスオーナー
- 開発デリバリーレイヤー - テクニカルリーダー
- テクニカル実装レイヤー - 一次開発
これらの 3 つのレイヤー、3 つのポジションは、やるべきことに対して異なる理解を持っています：
- ビジネスオーナーの視点。ビジネスの視点から出発し、ビジネス計画を立て、ビジネスの目標を設定し、デリバリー後の価値検証を行い、ビジネスのフィードバックに基づいてビジネスを改善します。3 つのノードのサイクルを形成します。
- テクニカルリーダーの視点。要求を継続的に、明確に、高品質で提供し、ビジネスオーナーの一部を担当します。製品の設計を定義し、一方で要件を発行し、システムの設計、開発テスト、システムのリリースを行います。
- 開発の視点。開発プロセスの視点から出発します。各開発活動が効率的で通常で低コストであることを目指します。
うーん、視点が高すぎます。専門用語が高尚すぎて読めません。続けます。
- 効率プラットフォーム。納品に関連することをこのプラットフォームで管理できます。
- 効率の実践。DevOps プロセスを抽出し、実践から経験をまとめます。
- 効率の測定。データから問題を見つけ、問題を改善します。
元の文章が理解できないので、口語にしてみました。
アーキテクチャ#
このプラットフォームは、納品に関連することを管理するために使用されます。機能のレイヤリング
- プラットフォームレイヤー。ワークスペース、プロセス制御
- ツールレイヤー。コード関連のサービス、パイプラインなど
- 共通サービスレイヤー。テナント、権限、通知など
ここには、レイヤリングのアーキテクチャ図がありますが、考えた結果、掲載します。
全体的には、いくつかの機能を細分化しています。Coding の使用経験がある場合、驚くことはないでしょう。後ろにはいくつかの図もありますが、描き方が良くないようなので、掲載しません。
フロントエンドのライフサイクルの視点#
要件 - 開発 - テスト - 統合 - 受け入れ - グレーディング - リリース - デプロイ。
いくつかの内容をスキップしましょう。みんなが良いコードが好きですが、いつが良いコードか：~~ 動けばいい！~~ 量化が必要です
- 可用性、異なるコード設定のバグ率
- メンテナンス性、複雑さ、認知的複雑さ、重複率
量化の背後にはいくつかの手法がありますが、高尚すぎて理解できませんが、一部抜粋してみました。使うことはないといいですが。
- ast 解析、baker アルゴリズム、行列カウント検出、rbin-karp 文字列検索
量化には公式が必要ですので、いくつかの公式と重み付けも指針として示されています。
えー、やめます。開発指標の量化作業をしたことがないし、PPT からの情報摂取は限られているので、一旦やめます。
钉钉前端 CICD 实践#
出典：https://ppt.infoq.cn/list/108
钉钉前端的 CI/CD 实践
孟红伦（云际）/ 阿里巴巴高级前端技术专家
- 敏捷开发
- CICD 和敏捷开发
- 钉钉前端实践
- 展望
敏捷开发の説明はいつも眠くなります。以前に雇った敏捷コーチもそうでした。
敏捷開発のビジョン、概念は省略します。
CICD の概念も省略します。
自動化テスト、ユニットテスト、統合テストを強調します。
- UI コードのテスト、テキストがドキュメントにあるかどうか
- インタラクション後のドキュメントの変化をテストする
- UI のレイアウトはテストしない
- テストライブラリの使用
- コードカバレッジの紹介
- 受け入れに時間がかかり、問題を見つけるために時間を短縮したい
以上です、次に進みましょう。
美团 B 端#
美团 Design-DevOps 在 B 端业务的实践
高振泽 / 美团前端技术专家
問題が発生し、フロントエンド開発リソースのボトルネックに直面しました。いくつかの問題の例があります。そのため、DevOps プラットフォームを開発しました。
わかりました、また別の Coding を実現しました。自分の問題を解決しました。
SOP 思想提升 DevOps 质量和效率#
SOP 思想提升 DevOps 质量和效率
孙东 / 58 同城 SaaS 应用大前端负责人
わかりました、また別の Coding を実現しました。自分の問題を解決しました。