Leaderboard

Whichever system you choose will require a lot of time and effort to implement by the whole team. Don't think that you can simply choose a tool that "feels right" and expect everyone to accept your opinion. I made that mistake and had to rethink my strategy after a disaster of a start (only one of us adopted the new system - me ). You also don't want to be responsible for everything, so it's best to have the majority on your side before you enforce a new system. Your main focus should be on your workflow and your requirements to decide which tools are right for you. For example, do you have small projects or big? how many developers work on a single project? are your projects deep (multiple projects in separate repositories), wide (multiple projects managed in a single repository), or flat (single repository)? do you always have access to your servers when developing? do you have a project leader, or is each project managed by a single head-developer? who are your stakeholders and which kind of reports, documents, and access rights to they need? how are bugs reported to your team? do you need to give access to your source code and bug trackers to third-parties (external)? what kind of development cycle is used for your projects? do you need to integrate additional platforms or tools (i.e. CRM)? While it is kind of easy to state those questions, the answers are not that simple to give. I still struggle to answer some of those (among other) questions and simply made gut-decisions where necessary. Also, don't forget to include your team in this! Simple questions like "Where do you struggle the most?" do wonders if you care to listen. Here is our tooling for reference: We use Git for source control, Jira for bug tracking, planning, and reporting, and Confluence for the wiki. Our developers are free to use any client they want (i.e. Sourcetree), as long as they adhere to the commit guidelines. We still don't have a working CI/CD solution, so each developer builds their own project (or in case of larger projects, the head-developer). Unfortunately LV is exceptionally slow in this area, especially for large projects. We are actually at the edge of what we consider acceptable. In the past we used ZIP files, later SVN. I don't think I need to explain why we went away from ZIP files. SVN, however, we discarded because it wasn't the right fit. Occasionally we have to change programs on-site, without server access, and want to be able to commit changes. SVN simply is too much effort for such a workflow. You need to remember to checkout and lock files before you travel and hope that nobody breaks the lock. Lessons learned from using SVN: Don't trust your colleagues 😱