“Our work would come to a standstill without DeployGate.” DeNA’s large-scale development staff members explain why they chose DeployGate.
DeNA Co., Ltd.’s mission is to “delight people beyond their wildest dreams,” and operates in various industries, including gaming, live communities, and sports.
The company uses DeployGate’s Enterprise Plan. Large-scale mobile game development often involves significant challenges in daily build distributions, test environment maintenance, and other tasks, due to the complications related to development and operational systems of globalization. DeployGate serves as a stable foundation for these large-scale and long-term projects.
We spoke to two individuals at DeNA about the background behind the company’s implementation of DeployGate, its day-to-day use, and the decision to replace internal tools. Mr. Mizumoto of DeNA’s Second Game Engineering Group, First Engineering Department, Development Operations Division, Game Services Business Unit. Mr. Yajima of DeNA’s Technical Operations Group, IT Strategy Department, IT Unit.
DeNA’s Global Game Development Team of 100
ー First, please introduce yourselves.
Mr. Mizumoto:I joined DeNA Co., Ltd. (DeNA) in November 2018 as a mobile game engineer, and I’m mainly responsible for release-related systems. I’m currently involved with maintaining a major global title’s development environment and operational flow.
This project is extremely large, and we’re working with various stakeholders, including internal development team members, collaborators, localization personnel, and QA staff. We’re striving for stable releases by developing multiple versions simultaneously and continuously delivering builds to various locations daily. As part of our efforts, we’ve implemented DeployGate for the title and are currently uploading builds continuously and working to improve operations.
Mr. Yajima:I joined DeNA in 2015 and started in the Network Group, where I was responsible for network operations in data centers and offices. In 2023, I moved to the IT Strategy Department, where my group manages tools and services used within the company.
I currently manage accounts and contracts for company-wide tools like Google Workspace and Slack, as well as tools used by business units, such as DeployGate. We manage a variety of tools, and I’m responsible for over 40.
ー What is your development structure?
Mr. Mizumoto:The Development Operations Division of the Game Services Business Unit, which I belong to, has over 500 members and is the largest in the company. My project has just under 100 members, including 20~30 engineers on the development team, plus various members across many disciplines, including designers, planners, and marketers.
While DeNA mainly handles development, we also work with external partners due to the nature of IP matters. Additionally, we outsource QA tasks and work with translation companies for multilingual support. We also incorporate LQA (Language Quality Assurance) to ensure that the quality meets globally accepted standards.
As our structure is large and multilayered, development is predicated on a long-term basis. For example, a single monthly update can actually involve almost one year of development. To deal with these situations, we work on multiple versions and fix bugs simultaneously, organizing updates by feature or event.
The key to stable operations - continuous merging and building
ー How do you use DeployGate on a daily basis?
Mr. Mizumoto:DeployGate is an invaluable tool for distributing builds daily. Not only do our engineers use DeployGate, but members of other fields also use it, including designers and marketers. Everyone can check builds whenever they need to do so.
Because we develop multiple versions simultaneously, we upload dozens of builds every day, each geared toward a different audience. Because DeployGate allows permission settings at the team level, we can configure it so that each member can only view builds appropriate for their role, ensuring smooth operations. It also reduces confusion and mistakes.
Additionally, for CI/CD, some titles use Jenkins, while others use GitHub Actions; we employ DeployGate for both. We incorporate automation, such as sending automatic notifications via Slack after distributing builds or automatically posting a downloadable QR code in a thread. With this automation, stakeholders can more easily access builds.
ー Are there any challenges when developing with external partners?
Mr. Mizumoto:Yes, I experience management and coordination challenges every day. For example, we occasionally have to provide four different apps simultaneously to our partners. We often use different version numbers internally and externally, so we must accurately understand and manage each build’s contents and specifications. We currently use spreadsheets and scripts to organize release statuses, but our QA team alone has over 100 members; it’s not an easy task.
Distributing apps under development is quite complicated, with platform structures being just one element. DeployGate makes it easier to deliver development builds and is invaluable in doing so to external entities.
ー What are some considerations or challenges with large-scale developments?
Mr. Mizumoto:With large-scale IP titles, multiple projects and updates are always underway at the same time. As such, if merging or build generation is even slightly delayed, it can affect the entire project's progress.
For example, if QA experiences a downtime of just one hour, a 100 person team will lose 100 hours. Even minor issues can lead to unexpected delays, so we must be mindful of all the details.
Considering all of this, we are very mindful of ensuring development and QA don’t stop. To maintain development speeds, continuous merging and stable build operations are critical.
Large-scale environments wouldn’t run without DeployGate
ー You seem to develop multiple versions and update frequently. Can you elaborate?
Mr. Mizumoto:We develop versions on separate branches, and for previous titles, each branch’s leader would integrate other versions’ branches and propagate the changes. However, because this phase is extremely complex, builds occasionally failed.
Now, we have a greatly improved automated system that propagates changes to other versions’ branches for each developer’s pull requests. By striving for more stable and efficient parallel development, we were able to solve these types of problems.
ー Are there any features that have been particularly helpful or uses that you’ve found valuable?
Mr. Mizumoto:While there are many features, including smaller ones, DeployGate’s stability has been the most helpful. We upload 30~50 builds daily, including some with large file sizes, but we’ve only had two or three instability incidents in four years. It’s extremely valuable to be hands-off yet have virtually uninterrupted service.
Additionally, UDID management for iOS builds is convenient, as we can view UDIDs from the Web UI. We can quickly check certificates and builds to see if everything’s correct without opening Apple’s Developer Console.
Furthermore, in terms of CI/CD, we greatly value the ability to configure permissions for each app. It’s quite helpful to manage access specifically for collaborators and QA.
I’ve actually been using DeployGate since 2015. At my previous job, I was on a small team of around five people. We installed apps from Xcode onto devices via USB, and our distribution workload significantly decreased after implementing DeployGate. Now that I’m in a large-scale development environment, I feel we’d be completely lost without it.
Mr. Yajima:I’ve been managing DeployGate as an administrator for several years, and I’m extremely grateful for its stability. Because so many people use the tool every day, it’s comforting to know that it’s hassle-free.
I also appreciate that it publishes its operational status on the status page and the official X page. We use many SaaS, but most services don’t publish this information.
As we have a lot of users, we can get an influx of internal inquiries if something goes wrong. However, we’re confident that DeployGate will respond to and address any issues promptly.
Smooth, 2-month transition from in-house tool
ー You probably use a variety of services to aid with your development. How do you usually implement them?
Mr. Yajima:As each service has different purposes and characteristics, we typically defer the framework preparation and decision-making to the field. However, the IT Strategy Department usually assists with common infrastructure elements, such as security and authentication.
For example, we have clear internal security procedures, and we ask field staff to follow the process. If necessary, we may work with the security division or the operating organization to implement the relevant measures.
We play a central role in configuring IdP (Identity Provider) integration. If the field requests the introduction of a new tool, we first make sure that they can log in via the IdP before handing it over to the field team. We also centrally manage accounts.
We use Okta as our IdP. While we were preparing for SAML integration, the field requested DeployGate’s integration, so we worked toward both. Around 2020, our company was shifting from on-premises to the cloud, so introducing a cloud-based service like DeployGate was only natural.
ー Did you consider introducing DeployGate when migrating to the cloud?
Mr. Mizumoto:Yes, it was exactly then. We previously used an internal distribution tool, so we had concerns about the ease of migration and users’ adaptation to the new tool.
However, the DeployGate staff and the IT Strategy Department diligently organized the information and provided clear and concise migration and usage instructions for each title. We feel that, despite migrating from an internal tool, the process of implementing DeployGate was exceptionally smooth.
ー Did the implementation proceed smoothly?
Mr. Mizumoto:It went extremely smoothly. The IT Strategy Department prepared everything from the contract to account management. They even provided step-by-step instructions guiding us to our accounts, so the implementation was hassle-free.
We only had to sort through the information we managed with our internal tools and adjust our own CI so it could handle the re-signing process. At first, we were concerned about the workload, as we also had our regular duties. However, thanks to our preparation, the transition went smoothly. We finished the migration within two to three months and resumed normal operations by the third month.
“Creating a tool is only the beginning” - Why we chose DeployGate
ー Did your work change after replacing your in-house tool with DeployGate?
Mr. Mizumoto:For the most part, our workflow remained the same. Even during the transition period, we continued development, so we experienced minimal disruptions when switching to DeployGate. We also provided guidance to our members that minimized issues.
Having said that, immediately after the transition, we noticed we couldn’t perform some tasks that we were able to before. Once we raised these issues with DeployGate, we were grateful for their quick response.
Post-transition, we noticed that it had many features that made operations easier. For example, scanning the distribution page’s QR code goes directly to the build page. Additionally, configuring the Android Keystore from the Web and viewing the iOS UDID lists make it easier to verify work and respond to inquiries.
Our internal tool couldn’t handle detailed work, so switching to DeployGate significantly improved our operations.
ー Would you bring things back in-house now?
Mr. Mizumoto:Personally, I see no reason not to use DeployGate. It would be challenging to create a development environment with the same standards. For example, I don’t think it’s realistic to create detailed features from scratch, such as viewing iOS UDID lists from the Web.
Developers tend to think that they can build things on their own. However, creating internal tools is just the beginning, as they require constant maintenance. You might lose the ability to manage such tools if a developer transfers to another department or leaves the company.
With DeployGate, we can focus on development, as they’ve shown their operational reliability. We appreciate this balance.
ー You mentioned that there were significant field benefits, but what drove the implementation decision? How about costs?
Mr. Yajima:I don’t think in-house tools are necessarily deal-breakers, but if going that route, you should clearly define the rationale, duration, and commitment requirements from the beginning.
Internal tools might reduce initial costs, but they require ongoing operations and maintenance. You also have to adapt to constant platform specification changes. You should consider whether the team could handle the workload over a one to two-year period.
To that end, I think DeployGate’s implementation was a success, because it made us assess what we could keep in-house and what we could outsource. We feel it was a reasonable decision, considering both operational needs and costs.
Pleasant surprise - requested features released after only a few months
ー You mentioned earlier that you raised some issues with DeployGate shortly after the transition. Could you explain what happened?
Mr. Mizumoto:Post-transition, the team frequently mentioned (and was concerned by) the inability to search for builds. Our in-house tools could edit and delete uploaded builds, but DeployGate initially didn’t have such features.
Around the same time, DeployGate sent a survey via the IT Strategy Department. We planned to discuss the issues anyway, so the timing was perfect.
Our survey response was more of an FYI than a request for changes or a wish list. However, we were pleasantly surprised that DeployGate released the requested features only a few months later.
Mr. Yajima:The IT Strategy Department conducts an annual company-wide survey about the tools we use. We also receive routine inquiries from users and extrapolate requests and wish list items, while vendors occasionally contact us for feedback.
DeployGate is one such vendor who not only established a forum for feedback but also showed a willingness to act. We’re grateful for their initiative and speed, as not all companies are as responsive.
Working together so the team can focus on the essentials
ー What would happen if DeployGate disappeared or became unusable?
Mr. Mizumoto:Honestly, we’d be lost without DeployGate. Obviously, we would look for an alternative, but I can’t think of a service that has the same standards as DeployGate in terms of features and functionality.
Many stakeholders use this tool, including developers, QA, and collaborating partners, so even if we could switch to a different service, it would involve a lot of time and effort - explaining to stakeholders, rebuilding environments, revisiting workflows, etc.
It’s not as simple as just replacing a tool. It would mean altering the development workflow and fundamental operational structure. It’s conceivable that our fieldwork would come to a standstill if we were suddenly unable to use DeployGate.
ー What’s so valuable that makes you think DeployGate is necessary for your operations?
Mr. Mizumoto:I think DeployGate’s stability is its greatest strength. Because we work with many stakeholders on our development projects together, being unable to distribute a build can affect the entire development. With virtually no issues or downtime, DeployGate is a reliable platform that has allowed us to operate without interruptions.
We also value the detailed features that our field teams appreciate, including build distributions via QR code and UDID lists. It’s a reliable tool that addresses our needs, including those that are difficult to bring in-house.
ー Lastly, what are you looking forward to in the future?
Mr. Mizumoto:We plan to continue to use DeployGate to provide stable builds. While we’re satisfied with the status quo, we would still like to see some improvement in its usability and convenience, especially on teams like mine that are responsible for multiple groups.
We will also consider how to develop games that will last more than a decade and provide good service to our users long term.
We can’t just create a game and call it a day anymore. We plan to automate as many non-essential development tasks as possible through CI/CD so that the team can focus on the essentials.
DeployGate is like the foundation that supports this kind of environment, and we hope to continue to rely on it in the future.
ー Mr. Mizumoto and Mr. Yajima, thank you for your time today!
