ButtonRealms
During this project, I had multiple roles during the 1 year of development we had.
-
Perforce administrator
-
Jenkins administrator
-
QA lead
-
Tech lead
Perforce
As the perforce master I was tasked with managing the perforce depot. As a learning objective, I decided to try to use perforce streams. After some research I decided on the following structure.
The structure was chosen to mirror the structure we had chosen for the team. We had split the development into two main groups, "Worldbuilding" and "Raiding". The other two streams on the bottom row were for Plugins and a stream that was hardly used. When a feature was finished in either Raiding or Worldbuilding it would be sent to the "Development" stream. This is where it would be integrated with the other systems and tested, before sending it to the mainstream. From the mainstream, the PS4 stream could merge down and make a build for the PS4.
The Networking stream was its separate stream on the networking programmers' request so that they could use automation on some of their processes. It also enabled us to reduce the size of the networking stream, because they were not working on the Unreal project, which we, therefore, could exclude from the stream.
Unfortunately, in practice this structure was a disaster, we lost a lot of time trying to merge and copy and a lot of duplication of features occurred. Therefore after iterating on the structure I came up with the much more simpler version down below.
In this structure, the development stream is where all of the active development is happening. The Networking and PS4 stream retained their purposes. The mainstream was used to create stable points and for testing purposes.
Jenkins
Jenkins was used for the automation of creating builds and testing the code of the project.
The days before a build had to be created were always a disaster. We never created builds except for the days that we needed to have one. However, almost always there were errors in the builds. Sometimes these took a long time to diagnose and fix. After a few of these disasters, I decided to do something about it.
At a certain time each day a build would be created automatically by Jenkins. This build was then used during the QA process.
Next to these daily builds I also created a Jenkins project that would compile the c++ code every time a change was detected in the c++ folder. This would give a quick check if the project was still compiling.
Both of these had a separate channel on slack that would send a message when they were done. These messages would be color-coded according to if they failed or succeeded.
QA
I decided to do QA to determine what bugs were in the project, to have a reason for the daily builds we were creating and to improve the overall quality of the project. I created a test plan using the GDD. This test plan was run through the newest build almost every day. The bugs were documented using mantis. In the end, the QA allowed us to showcase the project anytime anyone wanted to see it. And because we tested each build we were never surprised when a bug occurred during one of these playtests.
Tech lead
As a tech lead my main goal was to improve communication in our team. As this was an issue the first few months.
I installed daily stand-up meetings. This helped tremendously with the communication inside of the tech team.
I also was the spokesperson for the entire tech team. This meant that I had a good idea what everyone was doing inside the tech team and when someone needed something I could mediate the communication.