We know that “post-mortem” is a term that is widely used in various criminal investigations. By analyzing the various subjects of crime and mentioning them in the “Post-mortem report” helps the mystery of crime to be revealed by conducting a thorough investigation on them. Today we will discuss how this “post-mortem report” plays an important role in modern software development as a medium of better communication across cross-team members.

Today I will highlight a few theories that are well related to some of the extents of software engineering. “Software engineering” is a method that divides the whole development process into smaller modules and moves towards the solution through detailed analysis. Each of these small modules is the sum of one or more problems.

The more you write code regardless of application or infrastructure, the more you desire to bring the best outcome of your writing when they are running as a realtime entity. And no way to deny that testing helps us to gain our confidence before going for production. So, why leave your infrastructure code without testing? In this blog post, I am going to introduce writing unit tests for your infrastructure in AWS.

Errors are sneaky, often remain hidden, smart and somehow get past no matter they are caused by any human action or any prevailing bug. This error often causes incidents in the running system causing a great negative impact on the team. To avoid the same mistakes in the future it is needed to document them properly which is often referred to as incident postmortem writing.

If you are familiar with IaC then you must have heard about terraform, right? Terraform is an awesome tool letting you to create, destroy, provision and configure your infrastructure as code. When terraform is instructed to run against some of its configuration then it creates a state file in the developer machine. This state file contains infrastructure configuration as applied by Terraform. But if you want to work on the terraform codebase as a team allowing terraform to create state file locally then every member will be in a great dilemma.

After installing Wordpress when you setup application it will create a file named wp-config.php in the root of the source code. This file contains sensitive informations like database url, username, password and database name. We need mask those values with fake one and replace them with original one before build process. In this post, I will discuss on keeping these values secret with EC2 parameter store and using them in Jenkins pipeline.

Regularly a DevOps has to perform different types of server provisioning, configuration with different architectures for deployment testing, applying and testing IaaC modules or for building dev/stage environment. Terraform is such a tool which helps us to build & manage infrastructure using different cloud vendor API. Ansible is another tool to automate infrastructure configuration changes. In this post, I will discuss on using Terraform and Ansible together to bring infrastructure in desired state quickly.

We write Dockerfile for packaging our application into Docker images. Dockerfile is a set of plaintext instructions with predeclared environment variables. These environment variable contains sensitive information such as username, password, remote database URL, bastion host IP etc. When secret variables will be visible in source code repository then code repository members can see them easily. Obviosuly, we need to tackle this situation! In this post, I will discuss on keeping these values secret in AWS, fetching and using them in docker runtime.

Jenkins is a task server which is highly used in performing CI/CD jobs. AWS CodeBuild is a service for performing source code compilation, build, testing and artifact generation for deployment. We can integrate these two services to scale our build, reduce build time, minimize billing and exploit the combined power of CodeBuild and Jenkins.

Travis CI is another popular CI/CD service which is free for open source projects with limited functionalities. In the free version, unlike Jenkins, Travis CI builds application in a dockerized environment whose underlying architecture can be seen in Travis build log. Travis CI comes with single YAML configuration file where we need specify parameters and configure them to perform successful build and remote deployment. In this topic I will be focusing only on writing Travis CI/CD configuration not signing up Travis CI and integrating it with github source code repository.