Developers Summit 2016 "What is a software development environment that improves productivity and quality that supports team development?"

Next, Mr. Shota Kondo, Application Development Section, Platform Product Development Department, Product Division, Internet Initiative Japan Inc. (hereafter, IIJ) gave a lecture titled "GitHub Enterprise and the culture of in-house development."

Mr. Kondo introduced the environment before the introduction of GitHub Enterprise and the points that improved after the introduction. IIJ was established as Japan's oldest commercial ISP and has solutions based on its own services and products. IaaS-type cloud (IIJ GIO) is one of the most active in-house development projects. Mr. Kondo is in charge of the development and operation of centralized management services for the self-developed routers “SEIL” and “SA” series, as well as the operation and management of GitHub Enterprise. The version control system at IIJ was a mess of teams. CVS, SVN in the old one. I temporarily used GitLab, which is a copy of GitHub, for verification purposes, but have been using GitHub Enterprise since August 2013. In the days before SVN, it was very difficult to change bugs that were not confirmed at hand, and it was very difficult to review by email. In addition, each department had its own version control system and ticket management system, which put a heavy burden on the developers involved in multiple projects. Considering the operational load and stability within the company, GitHub Enterprise was finally adopted.

As of February 2016, 280 seat licenses have been used. There were over 3,000 public and private repositories. It is mainly used for project development, but there are also personal tools, patches, daily reports, weekly reports, and document repositories. GitHub Enterprise is operated by three people, but there are no particular obstacles and nothing special is done.

In the era of GitHub Enterprise, when we actually introduced it, the web service of GitHub Enterprise itself became a portal for development. Mr. Kondo was happy that he could see any project by looking at this portal. Also, by gathering all the scattered code in one place, tools and libraries that were in the repositories of projects that we were not involved in were gathered in a place where we could see them. Not only that, in terms of recruitment, when I went to the university I attended and said, "I operate GitHub Enterprise," the reaction was so good that I got reactions from students. I feel that it is an advantage that those who use GitHub can naturally blend into the development flow if they have been using GitHub since before joining the company. As an advantage of GitHub Enterprise when compared to GitHub, it is very uneasy to put code that cannot be released outside the company on GitHub on the Internet, so it is very advantageous that it can be operated in-house. . My favorite feature is pull requests. A pull request is a request to create a git branch and incorporate changes, so you can work on the main stream (git master branch), but you can review and discuss on the browser. The pull request function has a “Like” culture called LGTM (Looks Good To Me). Engineers feel motivated to work hard when they are praised, so they are very happy to receive LGTM comments from other developers. Another advantage is that you can view the code without logging in. This is because anyone can access it, so even employees outside the project can submit opinions and requests from a user's or developer's point of view. Contributions are expected from developers. Pull requests are sent from people who are not involved in the project, so we gather suggestions and ideas such as ``There was such a problem'' and ``It should be better like this''. There are other things you can do to prevent reinventing the wheel. You can avoid writing the exact same code in another project, which can be unproductive. It is good that joint development can be done by sharing repositories and code.

In fact, these are the “social coding” cultures advocated by GitHub. This is collaborating with others through code. It's a culture of being open to sharing code, allowing anyone to refer to it, feel free to share ideas, contribute, and create products together.

By introducing GitHub Enterprise, the development flow will naturally follow the GitHub Flow, the development process will change, the development culture will gradually change, and eventually an organization of engineers will be created to create products together. I think so. At IIJ, individual tools and code are beginning to be released little by little. (Attendance management tools, configuration generators for servers, etc.) For this reason, I have the impression that the culture of social coding is taking root little by little.

Finally, from Hirota, even if you use good development tools, it is possible that the development process and development culture will not change, but without good tools you can't even change anything. I would appreciate it if this lecture would be an opportunity for you to conclude the performance. Thank you very much for reading this far!