前言 上一篇文章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
前言 项目开发时间不算紧张,知道项目应用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, 下拉到页面



Copyright 2018-2019 Tanθ's Blog   |   辽ICP备19017651号-1   |     站点总字数: 276.4k 字   |   载入天数...载入时分秒...   |  站点地图   |  站长统计
  总访问量:  次  总访问人数:  人

博客内容遵循 署名-非商业性使用-相同方式共享 4.0 国际 (CC BY-NC-SA 4.0) 协议