How We Organize Our GIT and Why

organizing git

All of the projects for Jay Nine, Inc use a very specific process in with our development projects. Everything in the project must be checked into a single version control repository: all of the code, testing scripts, database scripts, build and deploy scripts, and anything else needed to create, install, run, and test your application.

This is for several reasons, namely:

  1. This makes it so that we have a ready-to-go back up of the entire application that we can launch at a moments notice
  2. When working with a team of developers, you can easily have multiple developers working on the project without a lot of hassle

If a bug is pushed live, our team has a rule that we try to fix it for ten minutes. If, after ten minutes, we don’t have a solution, we’ll roll back to the previous version in our version control and fix it from there.

This is auto-synced with our live websites, so when we make little fixes and update, checking in the completed code will automatically update the website (allowing for continuous deployment).

The GIT folders are organized very simply like this:

  1. The “Application” folder contains all of the necessary code that comprises the application
  2. The “Database” folder contains the latest copy of the database, in an executable format to create a new database if needed
  3. The “Documents” folder contains all of the project documents on how to use the project (end user manual) and how the project code is broken down
  4. The “Publishing and Testing Scripts” folder contains all of the documentation needed to publish the application in its environment, how to test the application to make sure no core functionality is broken, and a rollback plan in case you need to roll back for any reason

This has allowed us to drastically squash live bugs, as the checks and processes in place ensure things go live safely. A common issue with the continuous roll out plan and the frequent changes to working software is when you have live bugs.

Live bugs generally mean two things:

  1. Live bugs = lost money.
  2. Live bugs = people pulling their hair out because the customer facing version of their product/software is broken. What if a key customer sees this? What is a partner of ours sees this?

The version control system we use removes this fear. On top of that, it ensures there is always a working, ready-to-go version of the software in case something really bad happens.

Share this post :