At Ubiqware, we are focused on helping other organizations to make their activity around software manufacturing and its operation as efficient as possible. To do this, we use DevOps as a reference model.
DevOps is a philosophy proposed by Patrick Debois, who gave the devopsdays name to an agility, development and operations conference after the success of his presentation at the Agile Toronto 2008 conference. This philosophy organizes the software development life cycle (SDLC) in eight phases, as shown in the following picture.
- PLAN: Planning a project implies translating the requirements provided by the client to project tasks (product backlog items in terms of Agility), checking that requirements are satisfied after the completion of the project tasks defined. If we define the acceptance criteria of the tasks through software tests (even better, if they can be executed in an automated way), we will be doing Test-Driven Development. An example of an agile project planning tool would be Jira, which is complemented by Confluence, the wiki-based document management solution from the same manufacturer.
- CODE: Once that we have defined a project task, it is necessary to implement it. In the case of software, this means to “code” it or translate it into source code. The source code of our software project (or of a component of our project, if it is organized, for example, in a frontend and a backend) will be committed to a code repository. In general, Git will be the reference technology to maintain source code repositories. We will use a Git workflow (or branching model), such as Git Flow, to organize contributions from team members and to trigger continuous integration cycles. Obviously, we must ensure that code is implemented with sense. So all the good practices of Software Engineering will be observed, with the corresponding code analysis by human experts and the always welcomed help of automatic code quality analysis tools (e.g., SonarQube). An example of a Git repository provider is GitLab (actually, it is more than that, as it is a holistic solution for software project management based on DevOps).
- BUILD: As we have source code in a repository, we should be able to build it at any time in order to be executed. For this, a build server will be used, which will allow building software under the same conditions (always using the same version of the operating system, compiler -in the case of using a high-level programming language that must be translated into a lower level executable language- or the necessary construction assistance tools -preprocessors, obfuscators, etc.-). In this way, we will avoid the consequences that everyone has ever suffered when “generating the software in my own computer”. The use of a build server will allow automating continuous integration (BUILD-TEST), continuous delivery (BUILD-TEST-RELEASE) and continuous deployment (BUILD-TEST-RELEASE-DEPLOY) cycles. Jenkins, CloudBees, GitLab CI/CD, Azure Pipelines o AWS CodePipeline are examples of CI (continuous integration) and CD (continuous delivery/deployment) technologies.
- TEST: After our software has been built, we must run all reasonably possible software tests, especially recommending investment in automated tests, being aware that there are tests that only a human can solve (for now 😊). Software testing is a discipline in software engineering which will inspire us for many articles, sooner than later. Selenium, Jasmine, Junit or NUnit are some popular test automation frameworks for different development development technologies.
- RELEASE: Right after the TEST phase, our software is “worthy” of being packaged and registered in an artifact repository, where the successive software versions generated are stored. An artifact is a binary deliverable from which we can deploy/install/execute software. Examples are .jar or .war (Java), .msi or .exe files for software installation on Windows, NPM packages of web applications or JavaScript libraries, .zip files, etc. Nexus, Artifactory, AWS CodeArtifact, Azure Artifacts or un registro Docker, como Docker Hub, son algunos ejemplos de repositories de artefactos.
- DEPLOY: An artifact in the corresponding repository can be copied to a runtime environment and install/deploy the software in it to start working. This type of process is typically automated as a stage of continuous deployment cycles in any of the technologies listed for the BUILD phase, or any other similar tool.
- OPERATE: Runtime environments must be properly sized and configured to ensure the correct operation of software. Typically, at least four environments exist:
- the development environment (each developer’s computer)
- the test environment (e.g., running the software in the develop branches of the source code repositories of the project)
- the pre-production environment (replicating the production environment as faithfully as possible, with the latest version in the main/master branches in the repos)
- and the production environment itself (with the latest version in the main/master branches).
Agile approaches for IT infrastructure management, with Infrastructure-as-Code or IaC as the reference approach, will make it easier to adapt to changing business and technology contexts, either in cloud providers or in on-premise environments. Any operating system (Linux, Windows, MacOS, etc.) executed natively or in any virtualization technology, container runtimes such as Docker, container clustering technologies such as Kubernetes, or cloud providers (adding serverless approaches to their virtualization services) such as AWS or Azure, are examples of infrastructure technologies/providers.
- MONITOR: This is unfortunately one of the phases that receives less attention, regardless of how vital it is to measure how we are performing to determine bottlenecks and to verify that SDLC management is getting better and better, through the incremental adoption of DevOps. In future articles we will see how to monitor the performance (functional and non-functional) of the software that we manufacture, the performance of the IT infrastucture on which that software runs, and how well (and poorly) we are performing as a team around the project management methodology and the DevOps philosophy, examining the indicators of all the toolchain involved in the SDLC. Technologies such as Elastic Stack or services such as AWS Cloudwatch and Azure Monitor, plus all the monitoring features of all the tools used to help us across the other seven phases of DevOps, are monitoring technologies examples.
Our next articles will comment in detail about each of the phases, the tools used in some of them, success stories and also, of course, some failure cases (which sometimes may even be of more help).
