前言 上一篇文章Git Worktree 高级使用 整体反应不错，这完全是日常开发中可以用到的奇淫技巧。微服务环境下，通常我们都会有多个 repo，高级用法好归好，但每个 repo 都按照高级用法进行配置，还是比较麻烦的，你看这不就有同学发声了嘛 说者有心，听者有意，那就写个脚本吧 Git Worktree 脚本 个人不是很擅长写 bash script，磕磕绊绊写了一个 worktree.sh，完全执行上一篇文章的整个过程 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 #!/bin/bash -e repo=$1 dir="${repo#

前言 上一篇文章 Git Worktree 大法真香 带大家了解了 git worktree 是如何帮助我同时在多个分支工作，并且互不影响的。但是创建 worktree 的目录位置不是在当前项目下，总感觉创建好的这些 worktree 不属于当前项目，这对于磁盘管理强迫症的我来说是十分难受的，今天就带大家了解一种高级用法来解决这个痛点 准备知识 在使用高级用法之前，你需要知道一点 bare repo 知识，我们先从你熟悉的命令开始 1 2 git init git clone https://github.com/FraserYu/amend-crash-demo.git 这两个命

背景 上一篇文章 保持清洁的Git提交记录，三招就够了 ，大家看过后有私下留言说这是非常好用的功能，我突然想到工作中用到的另外一个 Git 功能那也是相当好用，必须全盘托出 作为程序员的我们应该都有一个感受，一旦进入某个项目，从开发，到发布生产，到 hotfix，到后期维护，那基本都有你的份，正在开发某个 feature，老板突然跳出来说让你做生产上的 hotfix 更是家常便饭，面对这种情况，使用 Git 的我们通常有两种解决方案： 1. 草草提交未完成的 feature，然后切换分支到 hotfix 2. git stash | git stash pop 暂存工作内容，然后再切换

背景 大家都有学习如何规范简洁的编写代码，但却很少学习如何规范简洁的提交代码。现在大家基本上都用 Git 作为源码管理的工具，Git 提供了极大的灵活性，我们按照各种 workflow 来提交/合并 code，这种灵活性把控不好，也会带来很多问题 最常见的问题就是乱成一团的 git log history，那真的是老太太的裹脚布, 又臭又长, 个人极其不喜欢这种 log 造成这个问题的根本原因就是随意提交代码。 代码都提交了，那还有什么办法拯救吗？三个锦囊，就可以完美解决了 善用 git commit –amend 这个命令的帮助文档是这样描述的： 1 --amend

前言 不知道你的 team 当中是否采用敏捷开发，总之我们的 team 贯彻敏捷方法很彻底 随着敏捷方法的步伐加快，如何加快软件的交付速度变得极为重要，快速交付离不开 DevOps，而 DevOps 技术栈中，Jenkins 绝对是 CI 过程的核心角色。要充分高效的使用 Jenkins，自然离不开 Jenkinsfile 什么是 Jenkinsfile？ 其实在前两篇文章中大家已经和 Jenkinsfile 照过面，只不过他们不是当时的主角： * Jenkins 使用环境变量 * Jenkins 动态使用分支名称 终于不用跑龙套了，在 Jenk

前言 在上一篇 Jenkins 使用环境变量 中，帮助大家使用一条 Docker 命令就可以快速玩转 Jenkins，同时用最简单的方式解释了 Jenkins 中让人混乱的环境变量，本文还是接着变量说点事情 一般成熟的项目流程都会通过 Jenkins Pipeline 来做 CI 部分，在默认 Jenkins 环境配置中，Jenkins Pipeline 分为两种： 1. Pipeline （单分支 Pipeline） 2. Multibranch Pipeline （多分支 Pipeline） 如下图： 如果使用了多分支 Pipeline，就不会存在动态使用分支名称的问题了。

前言 Jenkins， DevOps 技术栈的核心之一，CI/CD 离不开编写 Pipeline 脚本，上手 Jenkins ，简单查一下文档，你就应该不会被 agent，stages，step 这类关键词弄懵，也能很快构建出 pipeline 的骨架 但是当向骨架中填充内容的时候，尤其如何利用环境变量（系统内置 ｜ 自定义），多数人都会变得比较混乱，浪费很多时间，本文就帮助大家快速通关环境变量 准备 如果你想一边阅读本文，一边实践，但是没有 Jenkins 服务可用，又想快速尝试，可以应用 Docker 一个命令快速搭建 Jenkins 服务 1 docker containe

写在前面 本来想写一篇「如何自定义Spring Boot Starter」，但是为了更好理解 Starter 的一些设计理念和其中的关键点，所以提前将一些细节内容单独提取出来讲解说明 在 Maven pom.xml 中，你经常会看到依赖项中有类似下面的代码: 1 2 3 4 5 6 7 sample.ProjectA Project-A 1.0 compile tru

阅读全文

前言 项目开发时间不算紧张，知道项目应用Jenkins 持续集成实现自动化部署，这个部署是如何实现的，向架构师取经研究之后做此记录. 部署架构拓扑图 以下是项目部署架构简易拓扑图，不包括Solr服务器的部署, Prod Env采用Cluster Deployment的方式. 运维人员搭建Jenkins服务器之后，每位被授权的开发人员都可以访问Jenkins 工作主页， 当push代码之后，统一在指定时间点build (Jenkins没有采用有push代码自动build的方式 ). 1. 开发人员Push 代码 2. Build QA1, 功能测试通过之后进行下一步 3. Bu

使用场景 开发人员build project 之后，build结果无论是成功还是失败，都要及时的通知组内其他成员了解最新情况，邮件通知这时候就派上用场，恰巧 Jenkins 提供了这么一个功能，不过该功能还是过于单一，如不能编写email template 来格式化邮件内容，但Extended E-mail Notification（Jenkins 邮件插件）实现了更高级的功能，接下来逐步看一下 Jenkins 邮件功能的配置 配置邮件服务器 以管理员身份登录，在 Jenkins 首页click Manage Jenkins, 然后 click Configure System, 下拉到页面