Collaborate between Development and Operations Teams is the key in the Agile and DevOps. This post will elaborate on three primary models on how to collaborate between Development and Operations Team.
Agile software development has broken down some of the isolation between requirements, analysis, development, and testing teams. The objective of DevOps is to remove the silos between development (including testing) and operations teams and bring about collaboration between the teams.
However, since there are separate teams and also fact the team may have niche skills rather than skills across the software development life cycle, there could a phased approach for creating a pure DevOps team.
There could be two types of DevOps team engagement –
Collaborate between Development and Operations
Model -1 Separate Dev and Ops teams.
Key Issue –
Lack of Collaboration between the teams they are silo-ed. However, it may be possible to merge the teams, so the key is to improve the Collaboration through Common interventions. As mentioned in figure, the development and operations (may even have testing teams separate) are separate –
- Interventions planned at regular intervals with no overhead processes.
- Teams keep separate backlogs but take each other’s stories in their backlogs.
- Ops team gets knowledge about upcoming features, major design changes, possible impact on production.
- Dev team understands what causes outage/defects better, improves Dev processes to reduce the impact (e.g. specific logging, performance testing for a cycle).
- Dev team improves the development process over time by understanding Ops defects/outages better.
Model -2 Pure DevOps
The teams may be merged although DevOps skills set (end-to-end skills in a software life cycles) may not be readily available.
- The embedded team can be created by hiring people with blended skills or cross-training / on the job learning by Dev & Ops teams for each other’s skills.
- Team has single backlog with both Dev & Ops tasks.
- Each team member is capable of selecting any item & work on it.
Model-3 One team with Ops Extension: Hybrid
When a pure DevOps team cannot be constructed, a model closer to the pure DevOps team can be constructed.
- The horizontal Ops team forms a backbone for all development teams. It provides 24^7 support and performs the tasks which have a larger impact on IT e.g. patch development.
- Few Ops team members can become part of the Dev team and perform tasks which are application-specific. An ops team member can become part of the Dev team. This Ops representative will focus on all the Ops activities which are this team/application-specific while all Centralised Ops activities will be taken by horizontal Ops team when speed is increased, deployments are faster. Then teams realise that support service levels start dropping. That is when teams realise the importance of collaboration between development and Ops teams. Reduce the length of the release documents and hand over time.
Streamlined Processes across the Delivery lifecycle from Development to operations
Here are the possible process models –
The process is important because where teams are merged, the new process that needs to be adopted becomes critical.
Model – 1 Devs and Ops separate
The Development Team may be following an agile approach say scrum. The Ops team may be following another process (ITIL). Here is how the process can be adopted –
- Dev in scrum and Ops in any iterative model.
- Iteration duration matches with Dev iterations.
- Governance team (programme manager) for conflict resolution.
- Few team members cross-participate in daily stand-up.
Disadvantages of this model are –
- Frequent conflict and less appreciation for each other’s work.
- Cross skilling of talent is not possible.
Model – 2 Dev and Ops separate but following similar processes
The development and operation team may be following an Agile approach say scrum (by the development team) and Kanban (by the operation team). Here is how the process can be adopted –
- One group does scrum and other Kanban as ONE team.
- Two different product backlog (PB) but a single product owner (PO).
- Dev team works on user stories and Ops team works on high priority Kanban product backlog (PB).
- Any interdependent work items are prioritised by the product owner (PO) to resolve dependencies on time. Daily stand-up by the teams.
Disadvantage
- Cross skilling of talents is limited.
Model 3: Unified process
When there is a unified DevOps team, they can follow a unified process like scrum ban.
Advantages
- Single product owner (PO) with one product backlog (PB).
- Based on history, planned vs unplanned effort considered across.
- The team works on the prioritised user stories.
- High priority is set to unplan high severity incident.
- A team member having expertise in that takes up and resolves.
- Cross skilling of the talents is possible
Application in projects
Continuous integration and Continuous delivery is not just about the technical implementation but it is also an organisational and cultural implementation. There can be challenges faced by the team while implementing the same.
The challenges may come from the client is not conversant with the practices. Similarly, with different people and process models, the team may face issues with capacity planning.
There can be challenges related to access control or security with multiple groups involved. The team has to take care of these challenges as they proceed with the DevOps implementations.
Step by step process of implementing Continuous Integration and Continuous delivery
- Use version control repository:– This is the first step and is necessary to start implementing CI. The main objective of using a version control repository is to manage all the Source Code Changes and other software artefacts using a controlled access repository. This provides the team with a “Single source point” so that all Source Code is available from one primary location.Configure the CI Server:- The CI server has to be configured within the project environment to continuously check for any changes in the Version Control repository. The main purpose of the CI server is to run an integration build by retrieving the source files whenever a change is committed to the version control repository. The CI server should support hard-scheduling of the builds on a regular frequency, that is every hour and should provide a dashboard and feedback mechanism where the results of the builds get published.Build Script for Automation: -Next step is to build automatically. Build scripts must be developed and implemented (which could be a single script or a set of scripts). That will automate the software build cycle which includes Coupling, testing, inspecting and other deployment processes. Developers from the teams that implement CI System should run different Categories of tests which includes Unit, Component, System, functional, regression to speed up the build process and cheek build quality.
This step is very important and critical in large projects. It helps in stabilizing Coding Conventions and Constantly monitors Code for
- Average Code Complexity
- Cover of Code
- Duplication of Code
- Performance requirements.
If any suspicious code is committed, the server should generate and publish warnings.
- Configure CI with automated Deployment
After the creation of each build, how a version of binaries should be automatically deployed to test servers. It helps in importing integration with customer system. After each fix, the customer may verify new versions.
Best Practices of DevOps
To reap maximum benefits of implementing Continuous Integration it is advisable to follow the best practices listed below –
The Code Quality Analysis.
- Commit Code frequently – One of the major advantages of CI is integrating early and often. So to utilize the advantages of CI, developers must commit the latest version of the Code frequently. Waiting for more than a day to commit Code may not be beneficial and prevent developers from being able to use the latest changes.
- Don’t Commit broken Code – A precarious assumption in any project is that everyone knows not to Commit Code that would not work on the version control repository system. The eventual mitigation of such risk is to have a well-featured build script the complies and tests source Code in a repeatable manner. A team member should always run a private build before Committing Code to the version control repository. It is required to make this process part of the development culture.
- Fix broken builds immediately –Broken builds is anything that prevents the build from reporting success. It may be a Compilation error or a failed test. When Operating in a CI environment, their problems should be fixed immediately. Fixing a broken build should be done on a high priority.
- Write automated developer tests – Build should be e automated in order to run tests for CI system. It is essential to verify that the software works using automated developer tests.
- All tests and inspections must pan –In the CI environment, 100% of the project’s automated tests must pass. For any build to pass, automated tests are as important as a compilation. Codes that have error will not work and if we accept such codes, it will lead to lower quality software.
- Run Private Builds-To prevent integration failure, the developer should run private build in the local environment before integration changes into the repository. Any defects found in a private build should be fixed before committing changes. This ensures less broken builds.
- Avoid Getting Broken Code:-Failure of the build will lead to wastage of time if developers get broken Code from the repository. Developers should get the latest Code only when the build failure is fixed.
Similarly to reap the benefits of Continuous Delivery, the delivery pipeline must be as smooth as possible. Some of the best practices that can be followed are –
- Production like environment– Throughout the delivery pipeline, keep the Dev, QA, Pre-prod/ Staging environment same or as close to a production-like environment. This helps in failing early and fixing fast.
- Practice feature toggle– Feature toggle allows the software to be delivered/deployed Continuously, but the incomplete features/functionality remains active. This enables the business to take the decision to go live anything.
- Strong Configuration management – Not just for Code, have strong configuration management for test scripts, DB schema deployment scripts, server configurations etc.
- Automate more– Other than User experience and few areas of testing that needs manual intervention, all other tests, process and deployments should be automated in the delivery pipeline. Automatic promotion to a higher environment should be practised.
- Some binary or deployable artefacts across the pipeline– Some binary artefacts or deployable artefacts reduce surprises in every deployment.
- Quick feedback from each stage – Instant group chats/display boards can help in faster feedback and better collaboration. It is also very important to fix the issues with its most priority.
Activities performed by a developer in a day in CI-CD environment.
Step-1 Check out the source code- Developers checks out program files that are required to be modified from the single source code repository.
Step-2 Modify the program- The developer works on changes and creates new program files as per requirements,
Step-3 Create a private build- The developers create a private build on the local system. This process includes self-testing to ensure that the functionality is working as expected (While creating a private build, latest updates from version Control repository are received in order to create a correct build, This can be done easily using scripts while programming private build).
Step-4 Commit changes- Once the private build is successful, the developer commits changes to the version control repository. Commit instance is followed by an automated build.
Step-5 Run integration Build- CI servers run on integration build on the changes committed to the repository. Ideally, CI server continuously polls the version control repository and as soon as some changes have been checked in, build is trigged. This can be chosen to be done at a regular pre-defined frequency. Build scripts can be written to automate many of the tasks like automate compiling, unit testing, deploying or any combinations of these.
Step-6 Report Build Status- Based on integration build progress, an alert is sent to the stakeholders about the success or failure of the build creation process. This ensures that appropriate action is taken immediately in case of failure. Generally, each tool has this feature inbuilt.
Step-7 Deploy Changes –Once integration build is completed and successful, it is deployed to target server or system. This is an optional step which can also be automated based on project need.
Role of Release Manager in DevOps Setup
Below are the key activities performed by the Release manager in DevOps setup-
- Lead multiple cross-functional teams to support releases.
- Co-ordinate with multiple cross-functional DevOps teams (Business, Development, QA and Ops).
- Define the release types, associated workflows and approval requirements.
- Identification of risks associated with the releases and plan for mitigation.
- Drive automation and continuous improve releases.
Conclusion
Collaborate between Development and Operation team is very important for a successful DevOps journey. I hope practising these guidelines will sure solve most of the DevOps troubles.
If you like this post please consider it sharing.
