AWS => Continuous Integration & Continuous delivery/deployment

TeamCity + PowerShell => AWS Cloud

PhoenixServers Pattern: Avoiding Snowflakes, we tend towards Immutable servers which is logical conclusion of PhoenixServers pattern where our continuous deployment process will tear down existing servers and rebuild new cloud server from latest base image and deploy code/configuration onto new servers.

Our Philosophy: Build code one-time and should be environment agonistic. By ‘Environment‘, I mean Dev, Stage, UAT, Production. Compiled code should be runnable across all the environments as long as OS and any other dependent software is same across the environments this includes but not limited to IIS, JBoss, Database, and any 3^rd party software like Reddis etc.,

Code doesn’t change by environment, it is just that each environment has separate database, configuration or cache server to name a few.

Software & Tools: TeamCity, PowerShell, AWS PowerShell, AWS CLI, TFS, SVN, & Windows 2012

Software Development Platform: .net, java, Postgresql, Talend, Spark

1. What is the end package that is being deployed? 
• .exe, .dll, .jar, .ear, .zip, .config, .txt, Etc.,
2. What additional steps involved during deployment?
• Update config/properties files.
• Change end system configuration like iis settings or jboss configuration.
• Setup schedule tasks, cron jobs, triggers etc.,
3. What additional post deployment steps?
• Post production deployment smoke test.

Continuous Integration & Continuous Deployment to lower environments

  

Continuous Integration

1. Developers check-in code to TFS/Git
• TeamCity listens to source control server change check-ins
2. TeamCity fetch changes onto build server
3. TeamCity compiles code and generates repositories (nupkg/jar/ear/zip)
4. TeamCity runs unit tests and selenium tests
5. TeamCity records build/tests success or failure
6. TeamCity sends out success failure group notifications
   
   
   
7. On Successful build, TeamCity connects to AWS S3 and pushes latest build output (nupkg/jar/ear/zip/config) and deployment scripts/configs to S3
8. TC calls AWS stack creation with CloudFormation template as the input
9. On Successful AWS Stack call, TeamCity executes DB change deploy*
10. AWS Cloudformation receives CloudFormation template and executes on AWS Cloud within VPC (virtual private cloud) by creating AWS EC2 instances. AWS Cloudformation also downloads all the code from S3 which was uploaded to in step 7.
11. EC2 instance
• For .net deployment, will initialize AWS PowerShell and run ps1 scripts which installs required software like iis etc., and deploys  code. This is done by running ps1 scripts on the server which is get called from userdata section of CloudFormation template.
• For java deployment, will initialize AWS CLI and run commands which installs required software like jboss etc., and deploys Hub code. This is done from userdata section within CF template
• PS/CLI script take responsibility of attaching pre-configured security groups to new EC2 instances and EC2 to Elastic Load Balancers.
12. Upon successful completion of code deployment, EC2 instances will send out email notifications utilizing preconfigured AWS SNS.

*DB Change Deploy: New framework has been developed for database change deployments.

• During development, db change scripts are checked into TFS to ‘In Progress’ folder.
• Once change is reviewed, developer then checks-in to TFS ‘Completed’ folder.
• Every domain model now includes a table ‘deploy_log’.
• TFS ‘Completed’ folder is monitored by TeamCity.
• During .net & Java code build process, a step DB-Deploy, is introduced within TeamCity build process which gets latest changes from TFS onto build server.
• Once code build is successful, DB-Deploy step will connect to data base and query ‘deploy_log’.
• ‘Completed’ folder scripts are compared with ‘deploy_log’ table and missing new scripts are executed.
• Newly ran scripts are then inserted into ‘deploy_log’ table keeping it upto date of all the scripts that are ran.
• This entire db-deploy process is by environment and by domain model.

Continuous Delivery to Production

For Production deployments, step 8 is manual and is triggered from TeamCity, by Configuration management group once a CR is signed-off by QA and Product management team in UAT.

For Production deployments, step 9 is handled by DBA group and is outside of Continuous Deployment process.

Continuous Delivery of .net & java code to production are one-click deployments from TeamCity.