We use cookies to keep our website secure, personalize your experience and for web analytics purposes. Read our Privacy Policy to learn more. By clicking Accept, you agree to our use of cookies.
For an enterprise with siloed operations and development, it’s not uncommon for there to be friction between the two departments. Developers create software, but they need collaboration from operations to open ports, provision resources, or provide permissions on various servers and environments. When operations and development clash, disagreements delay productivity and deployment of software. To alleviate much of the contention and speed up software delivery, DevOps with modern CI/CD creates a collaborative environment where the two teams merge and work together to provide a better end-product.
Changing culture among teams is a delicate process. You can create a DevOps team from new hires or work with people already a part of the business. Whichever direction you decide to take, the team you create will be different culturally from the original operations and development teams. The change is for the better and most teams work much better in a DevOps environment rather than siloed.
Agile is a common factor among DevOps teams in the enterprise. This change might be standard in development, but operations staff are not typically working in an Agile environment. When you create a team, Agile will be a part of the process to help facilitate better communication and build on an operating standard that allows for changes and better deployment of software in a faster time frame.
Traditional IT uses change control and testing resources, but the heart of DevOps is the CI/CD pipeline. This pipeline alleviates much of the manual commitment required by software developers. In traditional IT, developers work with operations to configure resources, and then at least one developer is designated as the deployment manager. Any deployments may or may not require approval signatures, but the bottleneck is the manual process necessary to deploy software.
In addition to manual deployment, developers must test their code in a testing and staging environment. For each step from testing, staging, and production, someone must deploy code to each of these environments. This takes the time of one developer or the organization must hire a full-time employee to take care of deployments.
Freeing developer time and speeding up deployments is where CI/CD excels. It’s the main component of DevOps that attracts development teams to it. The first step in the software development pipeline is development to a testing environment. This step is the easiest to automate and usually where DevOps begins its changes.
After developers finish making changes to code, it’s checked into a repository. If developers check in buggy code, it usually isn’t found until after testing which could be days or weeks later. With continuous integration (CI) tools, developers can automate the process of building the codebase after changes are made.
Testing automation can be done by several tools. Popular tools include Selenium (for browsers), GitLab CI, Jenkins and Travis CI. These tools will build the codebase and automatically deploy it to a testing or staging environment if necessary. If bugs are found, the developers receive an alert so that they know changes must be made. The advantage of using CI automation is that bugs cannot be introduced into the codebase and left to persist until it’s too late. Developers are notified immediately so that they can fix the bug before it’s sent to production.
Most development environments have a staging environment as well, and it’s the same process when you move to DevOps. CI tools can be used to automate delivery to a testing environment and a staging environment where a quality assurance (QA) team can test it. Testing in the staging environment is a combination of manual and automated testing. In DevOps, you can often skip a testing environment and move code directly to staging.
After code is tested, it’s time for promotion to the production environment. There are two types of continuous promotion to production: continuous delivery and continuous deployment. Continuous delivery tools provide users with an easy way to promote to production. All activities (e.g. backups, code promotion, SQL scripts, etc) are automated using delivery tools, but a user must still trigger the action. For instance, most tools have a button users click to start the promotion. With continuous deployment, the entire process is automated. Code is automatically taken from staging after being tested and deployed to production.
Some of the tools that do continuous integration also perform continuous delivery and deployment. Jenkins, Travis and GitLab will automatically deploy to production. Octopus is a tool dedicated to delivery and deployments. Continuous deployment is where most organizations want to be, but continuous delivery is a great first step. Continuous delivery lets you start with simple promotion automation that still must be triggered manually and then code is sent to production. Once you get the bugs fixed, you can add full automation to the deployment process.
Let’s say that you’ve already set up your automation procedures and CI/CD tools are configured to work with your codebase. Even though the process works smoothly now doesn’t mean you will never have issues in the future. Operations could make changes to infrastructure configurations. Servers could move to new locations on the network, or a temporary network outage could interfere with deployments. Numerous issues can cause your automation to throw an error or simply stop working. The way to avoid a sudden unforeseen stop in the automation process is to ensure good monitoring tools are implemented.
Your DevOps team should choose the right monitoring tools that will work directly with your CI/CD tools. Monitoring tools can be much more expensive than the CI/CD open-source tools, but they are necessary to avoid a serious outage. New Relic, Dynatrace and AppD are a few monitoring tools that you can consider.
You’ll notice in many of these tools that analytics span more than just code deployment automation. DevOps can monitor the production application performance and any bugs detected during execution. This gives the development team the ability to remediate bugs before they affect user experiences or leave the application vulnerable to exploits. Monitoring applications help developers be proactive rather than rushing to fix issues causing downtime on critical applications.
The downside to excessive monitoring is the amount of log files generated. You’ll need extra storage space to handle the increased log files and space needed to perform analytics. Logs also accumulate fast if you choose to work with containers and microservices. Each service will have its own logs and analytics so that you can review performance. You could potentially have millions of log entries to review and use in your analytics.
Another common issue with large applications integrated with analytics tools is the hit on performance. Always test these analytics applications thoroughly to ensure that performance isn’t harmed. With millions of log entries and analytics tools executing in the background, your critical applications could suffer from performance degradation. Analytics software should be tested in staging, which is a mirror image of the production environment.
When you design a DevOps team, you have several tools to choose from but the overall modern pipeline has the same steps. The following steps are what you should expect to design and implement into your development lifecycle with a DevOps team:
