cicd_module-initial commit (#122)
* cicd_module-initial commit * Fixed the broken links in CI/CD course * Fixed the broken links and image links in CI/CD course Co-authored-by: Krishna Nukala <krnukala@microsoft.com>pull/123/head
@ -0,0 +1,19 @@
|
||||
## The Evolution of the CI/CD
|
||||
|
||||
Traditional development approaches have been around for a very long time. The [waterfall model](https://www.linkedin.com/pulse/waterfall-model-shobika-ramasubbarayalu) has been widely used in both large and small projects and has been successful. Despite the success, it has a lot of drawbacks like longer cycle times or delivery.
|
||||
|
||||
While multiple team members are working on the project, the code changes get accumulated and never integrated until the planned build date. The build usually happens on agreed cycles that range from a month to a quarter. This results in several integration issues and build failures as the developers were working on their features in silos.
|
||||
|
||||
It was a nightmare situation for the operations teams/for anyone to deploy the new builds/releases to the production environment because of lack of proper documentation on every change and the configuration requirements. So, to deploy successfully, often it required hot fixes and immediate patches.
|
||||
|
||||
Another big challenge was collaboration. It is rare that the developer meets the operation engineers and does not have a full understanding of the production environment. All these challenges have given rise to longer cycle times for the delivery of the code changes.
|
||||
|
||||
[Agile](https://www.linkedin.com/pulse/list-popular-agile-methodologies-used-organizations) methodology prescribes the delivery of incremental delivery of features in multiple iterations. So, the developers commit their code changes in smaller increments and roll out more frequently. Every code commit triggers a new build, and the integration issues are identified much early. This has improved the build process and thereby reduced the cycle time. This process is known as *continuous integration or CI*.
|
||||
|
||||
The big barrier between the developers and the operation teams has been shrunken with the emergence of the trend where organizations are adapting to the DevOps and SRE disciplines. The collaboration between the developers and the operation teams is improved. Moreover, the use of the same tools and processes by both the teams has improved coordination and avoided conflicting understanding of the process. One of the main drivers in this regard is the *continuous delivery (CD)* process that ensures the incremental deployment of smaller changes. There are multiple pre-production environments also called the staging environments before deploying to production environments.
|
||||
|
||||
## CI/CD and DevOps
|
||||
|
||||
The term **DevOps** represents the combination of Development (Dev) and Operations (Ops) teams. That is bringing developers and operations teams together for more collaboration. The development team often wants to introduce more features and more changes while the operation teams are more focused on the stability of the application in production. A change is always taken as a threat by the operations team as it can shake the stability of the environment. DevOps is termed as a culture that introduces the processes to reduce the barriers between developers and operations.
|
||||
|
||||
The collaboration between Dev and Ops allows better follow-up of end-to-end production deployments and more frequent deployments. So, thus CI/CD is a key element in the DevOps processes.
|
@ -0,0 +1,19 @@
|
||||
## Applications in SRE Role
|
||||
|
||||
The Monitoring, Automation and Eliminating the toil are some of the core pillars of the SRE discipline. As an SRE, you may require spending about 50% of time on automating the repetitive tasks and to eliminate the toil. CI/CD pipelines are one of the crucial tools for the SRE. They help in delivering the quality application with the smaller and regular and more frequent builds. Additionally, the CI/CD metrics such as Deployment time, Success rate, Cycle time and Automated test success rate etc. are the key things to watch to improve the quality of the product thus improving the reliability of the applications.
|
||||
|
||||
* [Infrastructure-as-code](https://en.wikipedia.org/wiki/Infrastructure_as_code) is one of the standard practices followed in SRE for automating the repetitive configuration tasks. Every configuration is maintained as code, so it can be deployed using CI/CD pipelines. It is important to deliver the configuration changes to the production environments through CI/CD pipelines to maintain the versioning, consistency of the changes across environments and to avoid manual errors.
|
||||
* Often, as an SRE, you are required to review the application CI/CD pipelines and recommend additional stages such as static code analysis and the security and privacy checks in the code to improve the security and reliability of the product.
|
||||
|
||||
## Conclusion
|
||||
|
||||
In this chapter, we have studied the CI/CD pipelines with brief history on the challenges with the traditional build practices. We have also looked at how the CI/CD pipelines augments the SRE discipline. Use of CI/CD pipelines in software development life cycle is a modern approach in the SRE realm that helps achieve greater efficiency.
|
||||
|
||||
We have also performed a hands-on lab activity on creating the CI/CD pipeline using Jenkins.
|
||||
|
||||
## References
|
||||
|
||||
1. [Continuous Integration(martinfowler.com)](https://martinfowler.com/articles/continuousIntegration.html)
|
||||
2. [CI/CD for microservices - Azure Architecture Center | Microsoft Docs](https://docs.microsoft.com/en-us/azure/architecture/microservices/ci-cd)
|
||||
3. [SREFoundationBlueprint_2 (devopsinstitute.com)](https://www.devopsinstitute.com/wp-content/uploads/2020/11/SREF-Blueprint.pdf)
|
||||
4. [Jenkins User Documentation](https://www.jenkins.io/doc/)
|
@ -0,0 +1,16 @@
|
||||
CI is a software development practice where members of a team integrate their work frequently. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible.
|
||||
|
||||
Continuous integration requires that all the code changes be maintained in a single code repository where all the members can push the changes to their feature branches regularly. The code changes must be quickly integrated with the rest of the code and automated builds should happen and feedback to the member to resolve them early.
|
||||
|
||||
There should be a CI server where it can trigger a build as soon as the code is pushed by a member. The build typically involves compiling the code and transforming it to an executable file such as JARs or DLLs etc. called packaging. It must also perform [unit tests](https://en.wikipedia.org/wiki/Unit_testing) with code coverage. Optionally, the build process can have additional stages such as static code analysis and vulnerability checks etc.
|
||||
|
||||
[Jenkins](https://www.jenkins.io/), [Bamboo](https://confluence.atlassian.com/bamboo/understanding-the-bamboo-ci-server-289277285.html), [Travis CI](https://travis-ci.org/), [GitLab](https://about.gitlab.com/), [Azure DevOps](https://azure.microsoft.com/en-in/services/devops/) etc. are the few popular CI tools. These tools provide various plugins and integration such as [ant](https://ant.apache.org/), [maven](https://maven.apache.org/) etc. for building and packaging, and Junit, selenium etc. are for performing the unit tests. [SonarQube](https://www.sonarqube.org/) can be used for static code analysis and code security.
|
||||
|
||||
|
||||
![](./images/CI_Image1.JPG)
|
||||
|
||||
*Fig 1: Continuous Integration Pipeline*
|
||||
|
||||
![](./images/CI_Image2.JPG)
|
||||
|
||||
*Fig 2: Continuous Integration Process*
|
After Width: | Height: | Size: 31 KiB |
After Width: | Height: | Size: 22 KiB |
After Width: | Height: | Size: 35 KiB |
After Width: | Height: | Size: 37 KiB |
After Width: | Height: | Size: 117 KiB |
After Width: | Height: | Size: 40 KiB |
After Width: | Height: | Size: 51 KiB |
After Width: | Height: | Size: 70 KiB |
After Width: | Height: | Size: 55 KiB |
@ -0,0 +1,19 @@
|
||||
## Prerequisites
|
||||
1. [Software Development and Maintenance](https://en.wikibooks.org/wiki/Introduction_to_Software_Engineering/Implementation/Documentation)
|
||||
2. [Git](https://linkedin.github.io/school-of-sre/level101/git/git-basics/)
|
||||
3. [Docker](https://linkedin.github.io/school-of-sre/level102/containerization_and_orchestration/containerization_with_docker/)
|
||||
|
||||
## What to expect from this course?
|
||||
In this course, you will learn the basics of CI/CD and how it helps drive the SRE discipline in an organization. It also discusses the various DevOps tools in CI/CD practice and a hands-on lab session on [Jenkins](https://www.jenkins.io/) based pipeline. Finally, it will conclude by explaining the role in the growing SRE philosophy.
|
||||
|
||||
## What is not covered under this course?
|
||||
The course does not cover DevOps elements such as Infrastructure as a code, continuous monitoring applications and infrastructure comprehensively.
|
||||
|
||||
## Table of Contents
|
||||
|
||||
* [What is CI/CD?](https://linkedin.github.io/school-of-sre/level102/continuous_integration_and_continuous_delivery/introduction_to_cicd)
|
||||
* [Brief History to CI/CD and DevOps](https://linkedin.github.io/school-of-sre/level102/continuous_integration_and_continuous_delivery/cicd_brief_history)
|
||||
* [Continuous Integration](https://linkedin.github.io/school-of-sre/level102/continuous_integration_and_continuous_delivery/continuous_integration_build_pipeline)
|
||||
* [Continuous Delivery and Deployment](https://linkedin.github.io/school-of-sre/level102/continuous_integration_and_continuous_delivery/continuous_delivery_release_pipeline)
|
||||
* [Jenkins based CI/CD pipeline - Hands-on](https://linkedin.github.io/school-of-sre/level102/continuous_integration_and_continuous_delivery/jenkins_cicd_pipeline_hands_on_lab)
|
||||
* [Conclusion](https://linkedin.github.io/school-of-sre/level102/continuous_integration_and_continuous_delivery/conclusion)
|