Hey All,
I have seen a lot of questions lately around what source control to use and why as well as some items about the best way to release things (meaning versioning releases and such). I’m also guessing that many don’t realize just how easy this can be and what tools to use. Also, something I haven’t seen much of are questions about what tools to use to manage your work, like who is working on what and what needs to be done. I would like to get a chat started about this.
So, my questions to everyone out there are:
What do you use for source control and why?
What does your release pipeline look like?
How do you manage your work?
What other tools do you use to manage your project?
If you have any other questions or comments about this stuff in general please feel free to post about it, I would love to hear it and I’m sure many will appreciate it.
Let me be the first one to answer 
- Git - it is very powerful, popular and most importantly decentralized - everybody has a copy of the whole repo and if your server dies for some reason, you can still work on your project.
- A few steps:
- Create a release branch from the develop branch
- Build the product
- Test
- Commit hotfixes if any
- Build
- Test
- Merge the release branch back to the develop branch
- Currently using JIRA which is great (way better than Version 1 that we used before)
- ReviewBoard for code reviews, Google docs to discuss/specify/brainstorm ideas, features, etc - the collaboration feature is great.
Sidenotes: For git we are using the “Successful branching model” - A successful Git branching model » nvie.com along with the git flow plugin which makes your life easier.
1 Like
I figure I should also answer my question.
We started out using Git. Indeed Git is a great tool and we loved using it. We would cut branches for each feature and create PRs for code review and then squash/rebase/merge. This went really well but we started finding some issues. The biggest was that Git has file size limits and repo size limits which we were starting to hit. We made sure from the start to not commit things that could be compiled as well as any unnecessary assets but games get large fast. The second issue we found was that PRs really aren’t that great for binary assets. If we wanted to really check out the work someone did then we had to checkout their branch. It worked well for art (like textures and concept art) and code but that was about it. We also had some issues around merging files because more than one person would work on the same file
When those issues became a problem we moved over to perforce. Perforce gave us a couple things, first off, at the time, there was no Git plugin for UE4 that could do what we needed so the non-devs would have to use the command line still for things like branching and rebasing. Our LD and artist really hated that :-). Perforce has a UI that can do everything we need. The UI to do everything was a big deal and the better integration (at the time) with UE4 was also a huge seller for us. We all work on 1 branch together now and each branch represents a sprint. Our team is small enough where we can do this easily but I would think that this would be tough for larger teams. The reason we all work together is because merging binary assets is hard, perforce will automatically lock the files so if I’m working on a level bp I’m the only one with it checked out and you know it and therefore will either ask me to check it back in so you can work on it or wait. This can be done with various Git workflows as well but it’s not as seamless as it is in perforce. This is another reason we did this. With perfoce via our provider we can also get some larger repo (depot in the case of perforce) sizes and larger file sizes. However, we pay for perforce now where we didn’t have to pay for Git. Another downside to this is if multiple programmers want to write code in the same file we can’t. Luckily for us we have a fair bit of abstraction to help avoid this and we only have 2 programmers that work in C++ which makes it a bit simpler.
In terms of releases, at the end of every sprint (2 weeks in our case) we merge our dev branch back into the main branch and cut a release branch with the latest code, assuming nothing went wrong in the sprint. This gives us the ability to go back and look at previous releases if we want to. We also make sure we play test at the end of every sprint which is why we cut a release branch every sprint. And, when we start releasing to the community we have the means to patch the code that is currently out there if there is a problem because that code will be frozen in time via the release branch. We can also release a previous version if there was a major problem.
For managing our work we started out with Jira which I personally love. However, when we moved to perforce we switched to Assembla for convenience and cost. For us Jira + Git(free) was about the same cost as Assembla and we didn’t lose any features, in fact we gained some in repo size. Assembla provides us with almost all of the same stuff as Jira and integrates source control management right into it. So we can reference tickets when we commit our code. They also give us all the other things like a wiki and team management which you can get from Git and Jira. Since all of this is in one place in Assembla, integration is a bit easier if you want to do things like reference tickets in commits and on a wiki and stuff. We use a modified scrum approach where we give our tasks story points and take on X amount of points per sprint and our sprints have a general theme to them (focused around a feature or set of features) and we make sure we have something stable and able to release at the end of each sprint (even if the release is just internal for play testing). The modified part comes with the fact that we don’t/can’t do stand ups so we do weekly meetings.
For general thoughts and collaboration we use OneNote. We just found it was easier to use because we can have drawings and notes together and it’s easier to expand as we have more subjects we need to discuss. And it’s easily usable on a tablet or phone.
Our team is located in NYC, NJ, Boston, and Georgia so we are pretty spread out. We use TeamViewer to share our screens during meetings and work sessions and we use TeamSpeak for chat. TeamSpeak was a bit easier than skype or gchat because it’s just a room that sits there and you can come and go whenever and don’t need an invite or anything and there is always only one of them. Most of the work we do, we do together, making having the feeling of collaborative space (TeamSpeak + TeamViewer + OneNote) invaluable. We also use OneNote as virtual whiteboard for our work sessions. We typically all do a bit of work during the week but on the weekends we are almost always on together working making having something like this worked out