Struggling with cross-platform development and adopting GitHub Enterprise

GitHub contributed greatly to sharing sources in the open source community and streamlining joint development. The now well-established "Pull Request" culture was nurtured at GitHub. Write new source code, "pull request" it, have someone else review it, and merge the code. This mechanism for jointly improving source code contributes not only to the efficiency of development work, but also to the improvement of the quality of source code.

While GitHub's merits are well understood, many companies have been hesitant until now. This is because "the source code cannot be stored in the cloud" from the viewpoint of intellectual property protection. However, this concern is being dispelled with GitHub Enterprise (an on-premises version of GitHub, so to speak) that can be used only within companies. In recent years, companies are rapidly adopting GitHub Enterprise.

FUJIFILM Software Co., Ltd. is one of the companies that implemented GitHub Enterprise to experience the code review culture. The company develops software related to photo printing. A typical example is the software for reception terminals installed in photo shops and consumer electronics retailers. We are also developing an app for smartphones that provides the same functionality.

For print reception, use a computer at the store and a smartphone for the app. In order to provide the same functions, it is necessary to overcome not only the differences in the terminals on which the software is installed, but also the differences in the development environment. FUJIFILM Software Co., Ltd. decided to share parts as much as possible and develop them in parallel.

However, the cost of merging source code in cross-platform development was beyond our imagination. Mr. Kazuki Oshima of the company says, "It became difficult to see the progress between different platforms, which led to a decline in development efficiency." At the development site at the time, the "trunk" directory, which was supposed to indicate the mainstream of the source code, was increasing at the same time. "trunk2", "trunk3", and so on, it seems that it is no longer possible to know which is the real mainstream, and the on-site sense of crisis is heightened, saying, "We can't proceed as it is!" So Mr. Oshima and others stood up.

“In order to restore order to the source code, which had been repeatedly developed in parallel, we carried out a large-scale refactoring. At the same time, it was an opportunity to refactor the development environment, and there was a voice from the site that they wanted to introduce GitHub.” (Mr. Oshima).

Mr. Kazuki Oshima, Imaging Solution Group,FUJIFILM Software Co., Ltd. Co., Ltd.

Improves the atmosphere of the development site, improves code quality, and reduces stress

When GitHub Enterprise was introduced, various changes were born in the development site. In the past, code reviews were face-to-face, and developers had to explain what they fixed. While using tools such as WinMerge, there was a certain amount of time and effort, and it was necessary to record the minutes in Excel.

After the introduction of GitHub Enterprise, there was no longer a need for face-to-face reviews, and reviewers were able to review on their own schedules on their browsers. Developers can move on to the next development after submitting a pull request. I have learned to use my time more efficiently.

The revision history meeting minutes were devised a little. Although you can see the revision history by looking at the pull request, it was necessary to meet internal requirements. In order to visualize quality, the company had to add categories such as "fatal defect", "major defect", and "minor defect" when modifying code. So I added some features that I needed. Such as adding boilerplate in reviews and aggregating data from the GitHub API.

Source code merging, which was chaotic before the introduction, has become much more efficient with the addition of cooperation with not only GitHub but also various tools. Currently, they are using `` Redmine'' for project management, ` `Mattermost'' for chat tools, and `` Jenkins'' for continuous integration tools. The company is gradually moving to a modern development environment, and Mr. Oshima says, "Deployment automation is the next challenge."

Occasionally, pull requests were buried and not reviewed, but the problem was solved by creating a tool to extract unclosed pull requests. It seems that young people at the development site voluntarily developed this function.

The culture of the development site has also changed. As mentioned earlier, previous code reviews were stressful for those involved, such as having to meet face-to-face to submit the minutes. However, by using tools such as static analysis and automated testing on the browser, Mr. Oshima says with a smile, "I have gained efficiency and mental stability." The relationship between reviewers and developers ceased to be confrontational, and awareness changed to "share issues that must be resolved with the entire team."

That is not all. A culture that celebrates good code has also sprung up. GitHub is like a social network where you can easily "like" something to show your praise and encouragement. It became easier to present sample code and give advice, and the atmosphere at the development site improved. “A good atmosphere produces good code,” says Oshima.

Automated testing and static analysis checking mechanisms have made small improvements easier. One day, the team tried to run an "Early Morning Petite Refactoring Marathon." This is to do a small (within 50 steps) repair for 15 minutes every morning. I made a rule that pull requests should be made on the same day, and reviewers should review them on the same day. Even if it was just a little bit, we proceeded with the renovation and focused on not accumulating.

Then, minor corrections that had been postponed until now were made one after another, and the internal quality improved day by day. After the introduction of GitHub Enterprise, the number of inquiries about software from the market has been halved, and the defect density has drastically decreased to 1/5.

Mr. Oshima enthusiastically said, "The advantage of GitHub Enterprise is not that it can be used, but that the fact that it cannot be used is a disadvantage. We will continue to develop while loving GitHub." .

Macnica supported FUJIFILM Software Co., Ltd. 's implementation of GitHub Enterprise. Tatsuya Nemoto, the manager of the company's AI & Software Business Department, Section 2, also took the stage and introduced details of the support system.

Mr. Tatsuya Nemoto, Section Manager, 2nd Division,Macnica AI & Software Business Department

Macnica is the primary domestic distributor for not only GitHub Enterprise but also CircleCI, and is well versed in modern development tools and also provides technical support in Japanese. GitHub's vision of ``coordination with other tools'' is provided to clients as a solution.

Macnica support system