If you are dealing with deployments on regular basis then choosing a good and stable deployment library which has certain features for deployment e.g. parallel deployments is mandatory.
We recently faced same challenges as previously we were using Ant for packaging and deployment, then moved to Gradle but after considering moving our infrastructure behind load balancers (to support more users and fault tolerance) we wanted to have tool which can enable us to be able to deploy to our servers in parallel behind load balancer.
For this purpose we explored and tried out a few tools to see which tool would fit better for a longer run in our scenario. List of the tools which we evaluated are following:
1. Ansible: While it does support parallel deployment, it is quite a large tool set and more of a server management and configuration tool. We are already using Chef for server management and configuration so going with this was not ideal for us.
We preferred Chef over Ansible due to the utility and customizations we can do via cookbooks and recipes.
2. Capistrano: This tool is based on Ruby and follows deployment to a custom folder which is customizable but expects every deployment to be working from a separate folder via symbolic link.
3. Fabric: This is a python based library which streamlines system administration and supports for parallel deployments across fleet of servers.
In the end we decided to go with Fabric due to the following reasons:
- Python is a more mature and widely used system administration language.
- A vibrant community and documentation.
- We are already using Python for some our tasks and plan to migrate other scripts (which are written in shell and php) to Python in the longer run.
Godaddy is one of the oldest and widely used domain services provider but after after having Route53 from AWS (Amazon Web Services) it is almost necessary (as per a developer and automation perspective) to move to Route53 or any other DNS provider which provides us APIs and other services to automate around the domains. Due to this requirements, I had to move a few domains to Route53 from GoDaddy.
Migrating domains from one DNS provider to another is a big decision and requires careful planning to avoid any down time. When we were doing this we planned this adequately and followed these steps which I believe can be helpful for others as well.
- Reduce TTL for every record to a few minutes so when we are moving they start sending traffic to Route53 immediately. This is not a required step but recommended if you want to test it quickly. If your current TTL time is in days or weeks then this will take that much time to go live.
- Export zone file from GoDaddy.
- Import zone file into Route53.
- Announce downtime for maintenance on scheduled date to your customers.
- Initiate transfer from Route53. Refer to #2 in references.
- Accept and authorize it from GoDaddy. Refer to #3 in references.
- Verify the changes.
- After completing migration, we will need to run the following for each record from zone file to make sure it is responding to DNS query both with name server and without it:
- dig +noauthority +noquestion +nostats myDomain.com
- dig +noauthority +noquestion +nostats myDomain.com @ns-AWS-DNS.
- nslookup -debug myDomain.com
- nslookup -debug myDomain.com ns-AWS-DNS.
- traceroute myDomain.com