If you're serious about your software, DevOps is not only useful but it's vital.
Delivering your software fast has become as important as developing it well, You either get your product on the market fast or someone else will.
Having a solid DevOps strategy leads to faster Integration, deployment and a higher quality product.
Despite the difficulty of getting two separate teams that both have their own ways of doing things to join forces,
DevOps is a way of handling the lifecycle of an application, itoffers the greatest value to businesses where speed of delivery provides a significant competitive advantage.
Make your software-building process into an automated pipeline and optimize it for speed of delivery. The software pipeline should ensure security, quality and stability by automating the building and testing
of infrastructure and applications and progressively prove their fitness by providing feedback (via tests), and when ready, deploy it to end-users.
The CI / CD approach makes it possible to increase the frequency of distribution of applications thanks to the introduction of automation
in the stages of application development. The main concepts related to the CI / CD approach are continuous integration, continuous distribution
and continuous deployment. The CI / CD approach represents a solution to the problems posed by the integration of new code segments for development
and operations teams (what is called in English "integration hell", or the hell of the integration).
Specifically, the CI / CD approach ensures continuous automation and monitoring throughout the application lifecycle,
from integration and testing phases through to distribution and deployment. Together, these practices are often referred to as the “CI / CD pipeline”
and are based on agile collaboration between development and operations teams.
A good CI/CD tool can leverage teams’ current workflow, to best exploit the automation feature and create a solid CI/CD pipeline, and give teams the boost they need to thrive. To be able to use CI/CD, you need to create or find a suitable tool to add to your development toolchain. There are various factors you need to consider when choosing a CI/CD tool :
Open Source or Proprietary , Hosting: Cloud, On-Premise or SaaS, Models and Costs, Usability, Learning Curve and Community Support, Integration with Other Tools, Security, Data Storage and Retention.
To choose the suitable one you must ask yourself few question such as :
- What’s the usecase this tool is designed for?
- Does the tool do one thing?
- Has it been in use for a while?
- How's it interface ?
- Can you configure it with code?
- What about complexity?
- What about documentation?...
The most important question : Can these various CI/CD tools affect you negatively at the long term ? Can Getting used to work on one specific tool adversely affect you getting familiar with other tools ?
As we know, project variation and client needs can put you in case to change the tools to respond to customer requests.
Answer this question with 2 points :
Continuous Documentation
The scripts which control the automated DevOps processes also serve as a form of documentation.
They include information about system, server, and software configuration, and they serve as a detailed generic record of the deployment process.
They become even more valuable as documentation when they are combined with the logs of deployment status updates,
which form timestamped records of individual deployments, and which can serve as a source for historical deployment statistics.
YAML
YAML is currently in favor for all kinds of configuration tasks, as it easy to read and convenient to write. Many people
(who have had to write YAML for a while) would strongly disagree with this sentiment however.
In the end it’s a question of taste, and YAML is one of the lesser evils. Your team will probably prefer YAML over XML, JSON or a DSL
they haven’t used yet when it comes to configs.
In the case of CI tools, it’s a convenient thing to have your pipeline defined as code along your project.
GitLab CI/CD uses gitlabci.yml files. Jenkins, on the other hand, can be configured to use Jenkinsfiles per repo, which need to be written in Groovy.
Top comments (0)