The ease in which Sync transports files between multiple endpoints makes it a useful tool for software developers. In this post I’ll walk through how Sync can be used for deployment as well as mirroring Git repositories – then we’ll look at extending these use cases with the developer API.
Sync for Web Deployment
The decentralized nature of Sync makes it an ideal candidate to help with deployment. Decentralized distribution allows for the quickest delivery of changes. The alternative – a centralized deployment system – can result in one machine being the choke point of the system.
From tens of servers to hundreds Sync can drastically speed up your Web deployment time. We’ve seen Angie’s List take their deployment time from hours to seconds. And because Sync is cross platform for Windows, Mac, Linux, and BSD – Sync should work within your existing infrastructure.
A basic configuration of Sync for deployment has one primary Sync folder which acts as the single source of truth. This folder should be provisioned with a Read/Write key. All other machines receiving the deployment should have Sync configured with the Read-Only Key. This prevents errors on the deployed machines from bubbling up and corrupting the primary source.
You may also want to ensure that the update is atomic from your user’s perspective. Keep in mind that not all of the peers you’re deploying to will be up to date at the same time. If you’re serving from the same folder that you’re syncing with you may inadvertently serve an old version from one front-end node and a newer version from another. Therefore, it may be best to ensure that all of your front-end nodes are up to date before switching over to the new version delivered by Sync.
Extending with the Developer API
For any non-trivial use of Sync for deployment you will certainly want to use the developer API to query the status of the peers in the swam. The “get_folder_peers” method of the developer API returns a “synced” attribute for peers which can be used to determine that all peers are up to date. This allows you to automate your deployment process by checking deployment status before switching front-end nodes over to the latest version.
With the “selective sync” functionality exposed in the developer API it is possible to facilitate more complicated deployment workflows. Selective sync allows for a peer to maintain a partial mirror of Sync folder contents – said differently, peers are able to choose the folder contents they want to sync.
Mirroring Git Repositories
Another developer use case for Sync is to mirror your local Git repository between machines. Not only will your repository be kept up to date between machines but your local uncommitted changes will also be mirrored.
Extending with the Developer API
Besides “selective sync” the developer API also allows for the creation of encrypted keys. Sync instances provisioned with an encrypted key for a folder only have access to encrypted versions of the files within a Sync folder.
With encrypted keys in mind, one way of improving the performance of your small swarm mirroring your Git repository would be to add an additional Sync peer with a cloud computing provider. Because the peer in the cloud would only be handling an encrypted version of your Git repository, if the cloud peer were ever compromised the attacker would not have access to your raw source code. You gain the benefit of having an additional peer in the swarm while minimizing the exposure of your source code.