This article describes DevOps Key practices which are described as below:
- i) CI/CD
When we use term “continuous” it does not mean that “always going” but of course “always ready to run”. Development philosophy and practices that drive teams to check-in code to version control system as often as possible is nothing but the Continuous integration. So maintaining your build clean and QA ready developer’s deviations need to be tested by running automated tests against the build that could be a Junit or iTest.
The goal of CI is to place a consistent and automated way to build and test applications which results in better collaboration between teams, and eventually a better-quality product.
Continuous delivery is an assistant of CI which offers a facility to ensure that we are able to release new changes to your customers quickly in a sustainable manner.
Typical CD involves the below steps:
- Appeal code from version control processes like bitbucket and implement build.
- Execute any needed infrastructure stage command script to stand up or tear down cloud infrastructure.
- Move to build compute environment; able to handle all the configuration generation process.
- Pushing software components to their suitable services, such as API services, web servers, and database services.
- Executing any steps required to restarts services or call service endpoints that are needed for new code pushes.
- Performing continuous tests and rollback settings if tests fail.
- Offering log data and alerts on the state of the delivery.
- ii) Keeping infrastructure in a secure and compliant way
Maintaining infrastructure secure and compliant is also a responsibility of DevOps or some organizations are nowadays pitching as SecOps. A traditional and basic manner of security performs or rules get fails when you have multi-cloud or a multi-layer system running for your production company and sometimes it really fails
When you are moving with the continuous delivery process, the job is to make sure that the team is giving clear and neat visibility on risk and weaknesses which may cause a big issue.
The basic rule to avoid small loophole (Specific to GCP) are listed below:
– Define your resource hierarchy.
– Make an Organization node and fix the project structure.
– Automation of project making which is useful to accomplish uniformity and testability.
– Manage your Google identities.
– Synchronize your existing identity platform.
– Have single-sign-on (SSO).
– Do not introduce multiple users instead of that choose resource level permission.
– Be particular while offering resource access also with action manner (Read, Write & Admin).
– Always use service accounts to access meta-data because to authenticate this it uses keys instead of password and GCP rotates the service account keys for code running on GCP.
– Implement VPC for network creation and create firewall rules to manage traffic.
– Define a particular rule to control and manage external access and evade having unwanted port opens.
– Define a centralized network control system which can be smeared across the project.
– Allow centralized logging and monitoring (Preferred Stackdriver).
– Allow audit log which is useful for you to gather the activity of Admin, System Event and Data Access in a phrase of who did what, where and when?
– Allow cold line data storage if there is a need to keeping a copy for disaster management.
– Additional reference for placing security principles and standards in AWS
DevOps Myths or What DevOps is not?
Before I mention the myths I would clarify the biggest myth which every early stage learner carries that “DevOps practice can be rolled out in a day and output will be available from the 1st day”.
This is too timely to spread this conclusion, as the definition of DevOps constantly says that it is a culture and process which may be built in a day. But of course, you will get an opportunity to overcome your mistakes at an early stage. Let’s discuss a few more myths:
- It is now only about the tool. It’s a component of the whole DevOps practice.
- Development and Operation team should have used the same agreed tools (How to overcome- push them to integrate both)
- Only new startups can use this practice (Azure has printed an article on best practices of DevOps which says it can be applied anywhere)
- Connecting to DevOps/ DevOps tool configuration with fancy sticker (Good you join but don’t pretend that now you are carrying DevOps tag)
- Assertive build in production in every five minutes (This is not what Continuous delivery)
- DevOps doesn’t fit the existing system (Overcome: You may need to find the right approach to make an attempt)