bazel

单体仓库与多仓库——两种源码组织模式介绍 单体应用和微服务应用 在介绍单体仓库和多仓库前，先来说说什么叫单体应用和微服务应用。 微服务相比单体应用最大的好处是可以独立的开发测试部署和扩展。单体应用一般采用单体仓库，但是微服务的代码仓库该如何组织呢？一定是每个服务一个仓库吗？ 其实也不一定，针对微服务的代码组织，业界有两种主要的实践，一种是多仓库（multi-repo）也就是每个服务开一个源码仓库，另一种叫单体仓库（mono-repo）所有源码都在同一个仓库中，尽管整个应用采用的微服务架构。 项目代码组织示例： 多仓库 单体仓库和多仓库都是有利有弊的。 多仓库的好处是显而易见的： 1.每一个服务都有一个独立的仓库，职责单一。 2.代码量和复杂性受控，服务由不同的团队独立维护、边界清晰。 3.单个服务也易于自治开发测试部署和扩展，不需要集中管理集中协调。 多仓库存在的问题： 1.项目代码不容易规范。每个团队容易各自为政，随意引入依赖，code review 无法集中开展，代码风格各不相同。 2.项目集成和部署会比较麻烦。虽然每个项目服务易于集成和部署，但是整个应用集成和部署的时候由于仓库分散就需要集中的管理和协调。 3.开发人员缺乏对整个项目的整体认知。开发人员一般只关心自己的服务代码，看不到项目整体，造成缺乏对项目整体架构和业务目标整体性的理解。 4.项目间冗余代码多

google为什么使用mono-repo 三丰 soft张三丰 什么是monorepo? Monorepo 它是一种管理 organisation 代码的方式，在这种方式下会摒弃原先一个 module 一个 repo 的方式，取而代之的是把所有的 modules 都放在一个 repo 内来管理。 目前诸如 Babel, React, Angular, Ember, Meteor, Jest 等等都采用了 Monorepo 这种方式来进行源码的管理。 git 多仓库管理的缺点 1.管理调试困难 2.分支管理混乱 3.依赖关系复杂 4.三方依赖版本可能不一致 5.占用总空间大 6.不利于团队协作 单体，多仓库，单体仓库 单体应用 到 多仓库 到单体仓库 单体仓库的优点：代码规范易于管理 配合自动化工具能够做到一键构建，一键部署 易于理解项目整体，开发人员有一个更好的全景视图 易于重用 谁在用monorepo bazel Bazel 是 Google 的一款可再生的代码构建工具。它主要是用于构建 Google 的软件,处理出现在谷歌的开发环境的构建问题,比如说:大规模数据构建问题,共享代码库问题,从源代码构建的软件的相关问题。 Bazel 支持多种语言并且跨平台，还支持自动化测试和部署、具有再现性（Reproducibility）和规模化等特征。Bazel

最近，在研究 Gradle 和 Java 相关构建的实现，让我对不同编程语言的应用构建燃起了一点点的兴趣。 不同编程语言编写的应用，在它运行的状态下，会有不同的运行机制，有的是以二进制的方式运行的，有运行在编程语言的虚拟机之上。而构建所做的事情呢，就是将那些我们写给人类看的代码，转换为机器/程序能看懂的代码。所以，构建的本质就是翻译(~~复读机~~)。 PS：本文旨在尝试性的整理我所了解的构建知识。部分内容限于对某一些编程语言的理解有限，并非非常准确。如有偏颇之此，希望大家指正。 引子 1：从 Java 的编译说起 绝大多数程序员都是从 hello, world! 开始自己复制、粘贴的人生生涯。对于那些刚上手 Java 的程序员也是类似的： javac HelloWorld.java 而当我们依赖于其它的软件包时，就需要在编译时和运行时加入 classpath 来加入依赖项。于是，对应的运行命令就如下所示： java -classpath .:libs/joda-time-2.10.6.jar HelloWorld 这样，我们就能得到预期的结果了： Hello, World Millisecond time: in.getMillis(): 1599284014762 而如果我们需要打成 jar 包就需要一个复杂一点的过程： jar cvfm hello.jar manifest

部分内容from: Tensorflow C++ 从训练到部署(1)：环境搭建 在之前的编译中，已经编译好了tensorflow_pkg相关的wheel。现在有一个需求，需要按照C++的代码进行模型加载和训练。查询资料后发现，需要重新编译一套TensorFlow支持的C++接口，主要是编译出来libtensorflow_cc.so和libtensorflow_framework.so这两个文件。 bazel build -c opt --copt=-mavx --copt=-msse4.2 --config=monolithic // tensorflow:libtensorflow_cc.so bazel build -c opt --copt=-mavx --copt=-msse4.2 --config=monolithic // tensorflow:libtensorflow_framework.so 像这种严格与机器相关的选项，虽然可以加快执行速度，但是在使用之前一定要查明自己的目标机器是否适合。 中间可能会遇到之前的一些问题，功查找https://www.cnblogs.com/jourluohua/p/9180709.html 编译完成后，安装第三方库 source tensorflow/contrib/makefile/build_all_linux. sh 若出现

这是关于Bazel的第二篇blog，前一篇写了安装、配置相关的东西，这一篇则是4个逐步推进的例子，改编自官方demo；以及相应的概念、文档链接等。 [TOC] 前提 Linux(Ubuntu, etc)或Mac OSX系统，会点儿命令行(包括brew/apt) 装好了zsh和oh-my-zsh（用于 bazel build 等命令的补全） 装好了bazel; 学过C/C++; 用过make/cmake 最好会一点git bazel版本：目前我用0.21版本，最新版删过东西（ https://docs.bazel.build/versions/0.21.0/be/workspace.html） 基本概念 WORKSPACE : 空文件；标识了项目根目录；只有一个 BUILD ：WORKSPACE下的子目录里，如果放了一个名为 BUILD 的文件，则这个目录是一个 package ； BUILD 里写一些构建规则 (rules) cc_binary : C/C++ package 的最常用的构建规则 bazel的C/C++在线文档： https://docs.bazel.build/versions/master/be/c-cpp.html target 的概念：cmake中的target包括executable、library两种情况 rule 的概念：类似于cmake中

转自： https://blog.csdn.net/elaine_bao/article/details/78668657 官网： https://www.bazel.build Github: https://github.com/bazelbuild/bazel 最近用到tensorflow的时候遇到了个新的编译工具Bazel，踩了无数坑之后终于决定还是系统地学习一下这货。 Bazel是一个类似于Make的编译工具，是Google为其内部软件开发的特点量身定制的工具，如今Google使用它来构建内部大多数的软件。Google认为直接用Makefile构建软件速度太慢，结果不可靠，所以构建了一个新的工具叫做Bazel，Bazel的规则层级更高。 下面就以C++和Bazel结合的例子理解一下Bazel的工作原理。 Install 安装过程请参考: http://bazel.io/docs/install.html 建立工作区（workspace） Bazel的编译是基于工作区（workspace）的概念。工作区是一个存放了所有源代码和Bazel编译输出文件的目录，也就是整个项目的根目录。同时它也包含一些Bazel认识的文件： WORKSPACE 文件，用于指定当前文件夹就是一个Bazel的工作区。所以WORKSPACE文件总是存在于项目的根目录下。 一个或多个 BUILD 文件