This post just a note to myself and it works on my environment. it has not been widely tested.
Just in my case, I cloned a git repo exists problems on the Windows platform with some folder, in order to work on the Windows platform we get a work around solution as following:
Case 1: when you not already cloned a repository
mkdir git-src |
Case 2: when you already cloned a repository
cd git-src |
git config core.sparseCheckout false |
相信许多程序员在新年开始在做 code sign (数字签名)的时候可能遇到 Verisign Timestamp 服务器不好用了 http://timestamp.verisign.com/scripts/timstamp.dll 的情况。出现了如下错误：
原因是 code sign 默认的时间戳服务器无法访问了。
在 Stack overflow 这个 post 里上面有人给出了答案，是来自于 Verisign Support 的回复：
他们的身份验证服务已出售给赛门铁克(Symante)，现在的服务商是 Digicert。该服务器已弃用了。
他们建议联系 Digicert 或在网络上找免费的 timestamp servers
以上是别人的回复，我在网络上没有找到一个官方回复，因此打算发邮件正式确认一下，发完不一会就得到了回复：
和上面的回复类似：几年前，Verisign 的身份验证和证书业务被出售给赛门铁克(Symantec)，目前已过渡到Digicert。您将需要与当前供应商合作以获得支持或更新的时间戳URL。请访问 http://www.digicert.com 了解更多信息。
好了，这下实锤了，放心大胆的开始动手修改到新的时间戳了。
我找到了 Digicert 的时间戳服务器是 http://timestamp.digicert.com。更换到新的时间戳服务器后，数字签名恢复正常。
除了上面 Digicert 那个网址，还有如下网址可以作为替换:
但我都没有选用，我还是选择了官方的时间戳服务，留作备用吧。一旦又抽风 “官方” 哪天又被卖了呢？
自 2020 年因疫情开始，越来越多的 IT 公司都因不得不在家办公从而彻底转为 WFH（Work From Home） 公司，因此对于 IT 从业者来说，工作机会今后将会是全球性的。
如果你有意想进入一个跨国公司工作，想与世界各地的人在一起工作，那么就不能仅仅的关注国内的这些大厂，要将眼光放眼到全世界，看看这些耳熟能详的公司对于工程师的职位要求有哪些。
今天就先来看看 DevOps 岗位的需求是什么样的，了解这些，一来可以帮助我们在2021 年树立学习方向，而来如果你有意向去这些公司，了解并提早做准备才能有机会获取你想要的岗位。
由于这些职位的介绍和要求会很长，因此我就先说结论。
具体的职位要求细节，请看后面的职位介绍吧 …
时间飞快，马上就迎来了 2021 年，又到了总结自己这一年来的所有的经历和收获的时候了。
2020 是非比寻常的一年，对于每个人不论是生活还是工作，都因为新冠病毒被影响着。
但生活总归要继续。刷微博、抖音各种社交媒体是一天；工作学习也是一天。我是那种一段时间感觉没进步就特别恐慌的人，做完后者总会让我感觉更安心一些。
对于 2020 年，我一直努力想要去做到最好，年尾回头看看，还算满意吧。
在年底写下工作工作总结的时候，发现自己这一年确实做了很多工作。除了做好构建和发布的本职工作之外，做了很多改进流程和提高效率工作，捡一些重要的来说：
通过 Jenkins Shared Libraries 和 Multi-branch Pipeline 完成了无人值守的自动化构建，为团队和我节省了大量的时间；同时也通过验证 PR 构建和测试，提高签入代码的稳定和质量。
推动团队迁移到企业级的 Artifactory 来下载和存储构建，从而改进 CI/CD 的效率和无人值守的能力。为更好的自动化下载、安装、测试等提供方便。
使用 Python 来做了很多关于 Jira, BitBucket 的集成，通过自动化提高效率。另外还发布了一个 Python 项目 UOPY。
落地了 Git 提交信息和分支创建规范，统一了 Git 提交信息和分支创建规范。
学习和使用了一些新工具，比如 Ansible playbook、ELK、JaCoCo 等并应用到项目中。
输出文章 初识 Ansible，JaCoCo 实践
作为 DevOps/软件工程师还需要有良好的表达能力，否则你做的东西再好，但无法很清晰的跟同事及领导分享出来也是事倍功半。尤其像我在外企，还需要用英文去做分享。
另外，我想通过坚持阅读和实践，让自己在技术上有比较大的提高。有一段时间我坚持的比较好，完成了好几本技术书籍的阅读，但好的习惯就怕被打破，一旦被打破就很难坚持了。之前一般都是中午午休的时间会阅读半个小时以上的技术书，后来常常因为中午要去新房盯装修，加上每天要做的事情很多（工作、学英语、阅读、装修）的时候，很多时候往往是事情做了，但效果并没有达到预期。
2020 年博客上一共更新了 41 篇文章，在公众号『DevOps攻城狮』上面一共更新了 26 篇文章。
这个数量和质量跟一些其他的技术公众号真的没法比，但对于我个人：一个不以写作为生、只写原创文章的攻城狮，只要能不间断的输出，达到这个数量我已经比较满意了。
而且在年初有一个清华大学的编辑老师找到我，想让我出一本书，这真是让我受宠若惊。我知道自己几斤几两，但能够受到邀请，并寄给我合同，就已经是对我写作的最大鼓励了。
当时打算写一本《Jenkins 2实践指南》，如果签了合同，我就需要投入至少一年的业余时间死磕自己才有可能完成。
最后考虑到自己当时的状况：优先做好工作；其次还有比Jenkins更重要的技术我需要去学习；另外周末要装修等一系列的事情…我最终放弃了这个机会。
我知道自己还处在输入比输出更加迫切的阶段，我想只要心中的小火苗还在，但行好事，莫问前程。
对于个人年终总结，不仅可以回顾自己过去的一年做了哪些，哪些没做好，有什么可以改进的，还能通过回顾和总结为新年立一个 flag。
2021 我希望自己能更加专注，利用好时间，更加有效的工作和学习。
除了做好工作，最重要的是提高英语口语和深入学习技术，其次才是输出。
光有 flag 不行，还要落到具体的行动上。
🚩 2021 继续坚持至少每天半小时口语打卡练习；另外每周一次 50 分钟的与外教的口语交流。希望能够脱稿进行英文分享，同时能通过英语托业考试。
我现在学习技术的方式有这么几种：直接去官网阅读英文文档；如果读完还是没搞明白，就去 Linkedin Learning 或是 Udemy 上去搜相应的技术，不但学习了技术，同时也练习了英文听力；如果需要深入系统的去学习一门编程语言以及一些底层技术，会去读一些经典技术书籍。
🚩 2021 年坚持每天也至少半个小时来阅读技术，一个月至少读完一本技术书籍并且有输出。
生活上希望家人和朋友都能身体健康，生活幸福。
🚩 财务稳定，最好能增长；自己能够健康生活，减重 10 斤。
最后，不时的来回顾自己 2021 年的 flag，时不时的看看自己是否偏离了最初的方向。2021 我来了！
过去的年终总结
I believe most of you have used the Jenkins configuration as code principle, so you build/test/release process will be described in code.
It looks like all is good, but not all of the configuration is in code, same of the Jenkins system configuration is store in the Jenkins service, so we also need to backup Jenkins in case of any disaster.
There are two ways to backup Jenkins, one used Jenkins plugin, the other is create shell scripts.
I used the ThinBackup plugin, here is my thinBackup configuration.
想要对 Java 项目进行代码覆盖率的测试，很容易就找到 JaCoCo 这个开源代码覆盖率分析工具是众多工具中最后欢迎的哪一个。
本篇仅仅是在学习 JaCoCo 时对其实现设计文档 https://www.jacoco.org/jacoco/trunk/doc/implementation.html 的粗略翻译。
这是实现设计决策的一个无序列表，每个主题都试图遵循这样的结构:
覆盖率信息必须在运行时收集。为此，JaCoCo 创建原始类定义的插装版本，插装过程发生在加载类期间使用一个叫做 Java agents 动态地完成。
有几种收集覆盖率信息的不同方法。每种方法都有不同的实现技术。下面的图表给出了 JaCoCo 使用的技术的概述:
字节码插装非常快，可以用纯 Java 实现，并且可以与每个 Java VM 一起工作。可以将带有 Java 代理钩子的动态插装添加到 JVM 中，而无需对目标应用程序进行任何修改。
Java 代理钩子至少需要 1.5 个 JVMs。用调试信息(行号)编译的类文件允许突出显示源代码。不幸的是，一些 Java 语言结构被编译成字节代码，从而产生意外的突出显示结果，特别是在使用隐式生成的代码时（如缺省构造函数或 finally 语句的控制结构）。
最近在思考如何将团队里的所有的虚拟机都很好的管理并监控起来，但是由于我们的虚拟机的操作系统繁多，包括 Windows, Linux, AIX, HP-UX, Solaris SPARC 和 Solaris x86. 到底选择哪种方式来管理比较好呢？这需要结合具体场景来考虑。
这里有一个关于 Chef，Puppet，Ansible 和 Saltstack 的对比文章
https://www.edureka.co/blog/chef-vs-puppet-vs-ansible-vs-saltstack/
如果你的虚拟机没有这么多平台，只是 Windows 和 Linux，假如你已经有了 VMware vSphere 来管理了，那么可以通过 VMware vSphere API 来查看这些机器的状态。
这里是 VMware 官方的 API Library 供使用：
如果你和我的情况一下，想监控很多个操作操作系统，那么就只能通过 ssh 来登录到每一台机器上去查看，比如执行 uptime 等命令。可以写 shell 脚本来完成这些登录、检测等操作。
另外就是使用 Ansible 的 Playbook。Playbook 里描述了你要做的操作，这是一个权衡，学习 Ansible 的 Playbook 需要花些时间的。
如果想了解下 Ansible 那么可以试试 Ansible Playbook。以下是我使用 Ansible 做了一些练习。
+- vars |
我在使用 Artifactory 做持续集成已经有一段时间了，对企业级 Artifactory 也有了一些经验和总结，希望能通过本篇的分享帮助刚接触这个工具的人了解什么是Artifactory，它能做什么，为什么要选择它，以及在使用过程中应该注意什么。
一句话概括：Artifactory 是一个存放制品（Artifacts）的工具。当前，Artifactory 是一个非常有影响力，功能非常强大的工具。
可能你的团队已经有了自己的管理制品的方式，比如 FTP 等。Artifactory 能带来什么呢？让我先来看看它有哪些优势。
注：以下优势都是针对 JFrog Aritifacvtory 企业版来介绍的。开源版，即 OSS 版本不具备以下丰富的功能。
JFrog Artifactory 企业版完全支持所有主要包格式的存储库管理器。它不但可以管理二进制文件，也可以对市面上几乎所有语言的包的依赖进行管理，如下图所示
因此，使用 Artifactory 能够将所有的二进制文件和包存储在一个地方。
本篇介绍个人或企业在 GitHub 上发布一个 Python 项目需要了解和注意哪些内容
打包和发布一项都是通过准备一个 setup.py 文件来完成的。假设你的项目目录结构如下：
demo |
在使用打包命令 python setup.py sdist bdist_wheel，将会生成在 dist 目录下生成两个文件 demo-1.0.0-py3-none-any.whl 和 demo-1.0.0.tar.gz
.whl 文件是用于执行 pip install dist/demo-1.0.0-py3-none-any.whl 将其安装到 ...\Python38\Lib\site-packages\demo 目录时使用的文件。
.tar.gz 是打包后的源代码的存档文件。而 MANIFEST.in 则是用来控制这个文件里到底要有哪些内容。
