Deploying code

Tony Mrakovčić

Lead Developer

With more complex projects developers need efficient deployment methods and at Degordian we make our own!

The motivation

When a young developer is faced with the problem of deploying code for the first time,the task mostly consists of uploading some kind a file to a server and that’s about it. As he learns and his projects become more and more complex, he realizes that he needs to develop some kind of structure and automation, as well as flow so that everything is in place and no step is overlooked.

At Degordian, we have always deployed code with in-house build scripts, mostly because of the way our projects are constructed and the simplicity they provide. We have a framework, an app/website that relies on it, caches, templates, statics, blah, blah…

When thinking about getting our stuff on the server we keep a few things in mind:

  • it must be easy to use – there should be only one “step”
  • there should be a backup of the older code
  • there should be a simple and fast way to go to the backup if your build breaks something
  • it should be easy to implement on a new server
  • it should be atomic – nothing should be down while it is “building”
  • we should be able to edit on the server without breaking the whole thing
  • every other secondary job (template cache flushing, framework building, backups) should be done within the build script
  • people should be notified when a build is complete

The implementation

The general idea how we implemented the script is relatively simple, when you think about it :)

The flow goes something like this:

  1. We have identical git repositories initialized on our server
  2. They are not browser visible, they are “in the back”
  3. We have a symlink in the browser visible folder that points to a symlink one path deeper – this link is the one the build script will repoint once it ends
utm tracking

The main reason for this approach is the atomic part. When everything is done and dandy, all we have to do is change the “inner” symlink to the new version and everything is upgraded instantly on the latest version.

Then, when you type the magic word “build” – a build starts!

First thing it does is create a file that if exists, another build process cannot be started. That’s just a little precaution not to wreak havoc on other code mid build.

Then, it checks which folder is the current live version, and this is written to a file which the script handles. Every time a build is successful, the number goes up, and resets to 0 if we have exceeded the backup number and need to start over.

Lets say the current version is 3. We position ourselves into repo 4 and git pull it.

Now that folder holds the latest version of the code.

The next thing we do is checkout the current folder.

This is something we do just to be sure that even if someone has edited a file on the server, everything will be committed and in order on the next build cycle for that folder.

We have a DIR_TO_REPOS array which handles which repo goes into which directory on the server. Here’s what it looks like:


DIR_TO_REPOS=(		
	"Degordian|git@github.com:degordiandev/framework.git"
	"apps|git@github.com:degordiandev/apps.git"
	"backend|git@github.com:degordiandev/backend.git"
)

And a for loop that handles it:

for info in "${DIR_TO_REPOS[@]}" ; do
	DIRECTORY=${info%%|*}
	REPOSITORY=${info#*|}
	cd $CURRENT_DIR$DIRECTORY
	echo -e "Updating $REPOSITORY repos in $CURRENT_DIR$DIRECTORY  \n"
	git pull
	cd $PREVIOUS_DIR$DIRECTORY
	echo  -e "Reverting for backup $REPOSITORY repos in  $PREVIOUS_DIR$DIRECTORY \n"
	git checkout $PREVIOUS_DIR$DIRECTORY
	cd ..
done	

So you can easily add a repo to the directory!

utm tracking

This is the “update” version of the script, there is also another flow that happens if the initial pull directory does not exist. This way it is easily portable to another server – it just clones the repo instead of pulling it and you’re on your way.

Then, we empty the template folder, since we have template caching in place.

After pulling all the repositories, we increase the CURRENT_INDEX value to 4 and repoint the inner symlink to folder number 4.

In case of a code break, what we did is implement a parameter we call “back” so the call looks something like “build back”

This simply just switches the symlink to the previous folder, and changes the CURRENT_INDEX file value to the same thing. It’s fast, simple and completely noninvasive.

After fixing the problem, there is nothing more to do except simply building again and everything is back on track :)

At the end, we exec a script that simply sends a message via gtalk to the people in our team telling them which server has been deployed.

There are a lot of ways of deploying code, and we have been expanding and improving our deployment technique for a long time. We are always willing to hear about other ideas regarding deployment so please don’t hesitate to comment and share your methods.

Interested in working with Tony and the Development team? Check out Degordian open job positions and join us!

 

Author

Tony Mrakovčić

Lead Developer

A developer with a strong passion for sitting. Capable of coming up with ideas that make no sense, yet mostly do. Has weird friends.

All stories by Tony

SIGN UP FOR OUR MONTHLY NEWSLETTER

Get more digital stories directly in your inbox.
Your email is saved
Join the discussion

No Comments

Share your thoughts

Let's work together  →
Go to top
css.php