BUILDING A DEVOPS CULTURE IN AN ORGANIZATION
INTRODUCTION
DevOps which stands for development and operations is a software development practice that promotes collaboration between development and operations, resulting in faster and more reliable software delivery. Commonly referred to as a culture, DevOps connects people, process, and technology to deliver continuous value.
It enables teams to work faster and efficiently but it will require reassessment and re-alignment of how people think about our overall business, customers and teams.
WHY IS DEVOPS NEEDED?
It is needed when the software development process is a highly manual process which results in a significant amount of code errors. Most times our development and operations teams can be out of sync and disappoint business stakeholders. The following examples would illustrate sample problems and how DevOps would eliminate a huge amount of them.
Example 1: Sample Situation
TEAM X is building an application for the organization. Team X consists of 4 Developers, A, B, C and D. A reproduces a minimal amount of code to build a feature but requires the features developed by B, C and D. They finally reconcile and prepare a working version. The business analysts, quality assurance and software testers require this working version of the product for review and so they take turns to request for the product.
The Product Manager wants this product to go live as soon as possible so he asks the development team to send a request for a Test server. This approval is granted but to access this server, the developers need to gain approval for their systems to be configured with access to be able to deploy the product to the test server. For the test server to be able to communicate with external services access needs to be granted. Finally, the product gets deployed to the test servers.
After the test, the same process is repeated over again before the product can go live on a production server.
Example 2: DevOps To The Rescue
Picture the same Team X in a DevOps environment. The Product Manager uses a tool called Redmine to create tickets(tasks) with IDs developers can pick and work on. Developer A, B and C reproduce minimal amounts of code to build a feature from a ticket. Because they use a tool called Git for source control, they can collaborate easily on Gitlab without having to wait for meetings to be able to share ideas. When they are done, Team Lead D can review their code during review sessions and approve or decline.
When a stage is approved, Gitlab will automate the entire process from test to production continuously in a pre-configured environment that includes all servers required and environment variables safely secured, completely eliminating all manual processes involved. At any stage of the software lifecycle, the business analyst, testers and quality assurance can review a ready version of the product.
With DevOps, we can derive efficiency from development, deployment and maintenance in the software lifecycle. It encourages and lays a strong emphasis on process automation thereby reducing code errors, increasing productivity and code efficiency.
DevOps PHILOSOPHY
The philosophy of DevOps is for developers to take end to end responsibility across the lifecycle of a project.
When developers work in silos — groups of developers that do not share information about what they are doing, they may not be interested in the maintenance of a product especially if it is handled by a different operations team. They want to code and present to the technical support team to maintain and operate. Developers can share the responsibility of maintaining and deploying the product so as to find out ways to simplify and better maintain the product. When the operations team works closely with the developers, they can better provide support for existing products and also adopt the latest automation tools and practices.
BUILDING A SUCCESSFUL DEVOPS CULTURE
To create a successful DevOps culture, you have to build a DevOps structure required to facilitate this process in the organization.
Assemble The Right Resources Required For The Team Structure
The roles required to implement a successful DevOps practice are described here:
DevOps Evangelist
He/she is the principal officer/leader responsible for implementing the DevOps practices and promoting the lifestyle within the organization. He also identifies the key roles and gets the development and operations team to work together as one, ensuring they are provided with the training required for them to excel in their roles.
Release Manager
This person is responsible for releasing new features and coordinating post-release product stability. He/she is responsible for the product life cycle.
Automation Architect/Expert
He/she is responsible for achieving automation and orchestration(design, implement and analyze) of tools and strategies required for DevOps practice within the organization.
Software Developer/Tester
Unlike the traditional approach where the developer writes and ships code, the developer is also responsible for writing unit and integration tests for code he wrote. He is also involved in the deployment and monitoring process of the application.
Quality/Experience Assurance
This person is responsible for functionality and user experience testing.
Security Engineer
He/she monitors the product’s security and health and also works together with the developers to ensure his recommendations are taken into consideration early in the life of the product.
Utility Technology Player
The team needs someone who can operate effectively across different platforms, tools, networks, servers and databases. He can apply knowledge from vast expertise to different areas within the organization.
Business goals should be aligned
Even though the team has been assembled, the business goals should be aligned with the team’s setup. In other words, the DevOps team’s objectives must align with the vision of the organization.
Select the right tools
I recommend Gitlab as the tool required for DevOps. This tool can properly align with any setup and team structure as it is an all-inclusive DevOps platform.
Measure the effectiveness of the team
There should be key performance indicators in place to closely monitor the effectiveness of the team structure, roles and the tools selected. Some examples of performance indicators could be: measuring the number of deployments happening per day, whether the security or quality standards are being met or not, the volume of errors and bugs reported and how efficiently they are being handled.
ADOPTING DevOps
Here are the key steps to implement a DevOps process;
- Define a source control and branch strategy
- Define the environments
- Setting up or configuring the CI/CD tool
- Configuring branch management
- Monitoring and logging
Define a source control and branch strategy
For teams to work together, a version control tool like Git is very important for efficient code management and accuracy. It keeps a snapshot of development files and lets developers go back to any version of their files. It helps prevent issues with conflicting changes.
A typical project will be made of 3 branches: Develop, Release and Master.
Develop branch is where development takes place. Developers collaborate here by branching off with the task IDs for features they are working on. These changes are then merged into the develop branch. The Release branch is where the QA and testing take place. Changes are merged into the release branch and versioned. Production code would be merged from the release branch into the Master branch.
Define the environments
Just like the branch strategy, the environments will take the same name corresponding to each branch. To this effect, there will be a development environment where all the development takes place, for example, the developer’s local machine.
QA/Test environment will represent the deployment environment for the deployed release branch. All testing will take place here.
The production environment is where the production code from the master branch will reside.
It is also important to note that there can be other environments depending on the requirement, for example, staging environment.
Setting up or configuring the CI/CD tool
GitLab is a very popular and complete DevOps platform, delivered as a single application, fundamentally changing the way Development, Security, and Ops teams collaborate. Once it is installed on the organization’s server, the configurations can be completed via the browser UI.
With Gitlab, continuous integration and deployment is possible within the platform. Gitlab automatically detects CI/CD configurations for every project through a ‘gitlab-ci.yml’ file that is situated at the root of the project.
Sample gitlab configuration file (gitlab-ci.yml)
The file contains scripts that run depending on situations like commits and more.
While Continuous Integration is the process of automating builds and testing code as soon as they are added to the source control system, Continuous delivery is the process that involves running extensive checks, tests and verifications to make sure code is production-ready.
Continuous Deployment is a process that enables fast delivery of reliable software. It is a step forward from continuous delivery in which production-ready code is deployed after every code commit and build.
Some configuration options include:
- Git push which is the most common event that triggers a pipeline,
- Unit and integration tests can be invoked within this pipeline,
- Static code analysis and code coverage can be configured,
- Continuous deployment and versioning,
- Code can be deployed to cloud-based instances like Microsoft Azure and AWS.
Configuring branch management
With branch management, we can monitor how code flows within the source control(git) and avoid situations like developers pushing code to master/production branch thereby introducing bugs to the system.
Here is a sample branch management process:
The developer creates a branch for his/her user story using the project management tool ID i.e Redmine ID.
- When development is complete, the developer creates a merge request off the develop branch.
- Gitlab CI/CD is triggered and a script runs to verify that there are no breaking changes,
- Team members carry out peer review session on the merge request and approve or decline with reasons,
- Team lead reviews the code, approves and merge into develop branch, Gitlab CI/CD is triggered once more to verify that there are no breaking changes,
- QA triggers the release branch job by merging the code into the release branch. Gitlab automatically versions the released code.
- If QA detects some bugs in the release, the developer makes a copy of the release branch, fixes it and the whole process here is repeated again.
- When QA is completed, the branch is merged into master and deployed automatically.
The advantages of this strategy are that developers have only “write” access to the develop branch and “read” only access to other branches thereby limiting bugs that may result as a result of conflicting changes and late commits.
Only tested code gets released by QA to the customers. There will be no conflicts as code will always follow the develop -> release -> master strategy.
Monitoring and logging
According to Microsoft Azure, the entire DevOps process creates a feedback loop with data points that can help improve other future projects and decision-making processes.
With monitoring and logging, learning can be supported, which can, in turn, help make informed decisions on optimizing and also continuously striving for better efficiency of the process.
CONCLUSION
Building a DevOps Culture cannot happen overnight. One of the challenges would be getting teams to collaborate and communicate effectively. Also, A lot of changes need to happen to the current team structure and organization for this to work. In the long run, a lot of benefits would be derived from the process.
