DevOps Lecture 2.0: Continuous Integration 4/10/23
The DevOps Way
GIT
-Jenkins
-This is the basis of what we’re doing with the DevOps pipeline
-Looking for events within DevOps pipeline
-Continuous Integration = GIT/Jenkins
Guidelines to Continuous Integration
Guidelines:
-Single source repository = GIT
-Multiple codes stored in a single repository
-Include as much automation as possible in your build
-Compile build along with whole pipeline
-The code will be automatically deployed
-Effective bug identification = a quick fix
-Deployment occurs multiple times a day, then small changes are made to
broken code based on feedback
-Assign team to fix issues
-Development Test and Production Environment (it used to be difficult to
work between both of these)
-EC2 instance machine is exactly the same as production environment (not
quite there yet)
-Shared responsibility model in DevOps
Best Practice for Continuous Integration
Best practice
-Bugs are inevitable but no feedback means less reliability
-Constant monitoring
-Fast fix = cheap fix
-Continuous web application (restricting access means no access for
multiple customers and less revenue for company)
-Commit at least once a day, sometimes a lot more
-Communicate to find out why your feature doesn’t work with someone
else’s (teamwork)
-Even small tasks should be automated as much as possible (manual =
point failure)
-Rollback (use an earlier version of code while fixing issue)
-Security needs to be baked in from the ground up
-Reliability = a team effort
The Benefits of Continuous Integration
Benefits
-Internal team
-Testing coverage (strict processes mean the code is the best it can be)
-Track bugs and see who’s taking responsibility for fixing, who deployed
code, figure out how to fix it (i.e., transparency)
-Continuous feedback from pipeline
-Automation = reliable code
, -Amazon, Google, Netlix (they have rare outages which means more
money for them)
-More responsive to customer feedback (functionality)
-More for less (more money and less effort = better productivity)
The Challenges of Continuous Integration
Challenges
-Difficult to duplicate the same versions, though it is easier now than
previously (duplicate environments in the Cloud)
-Shared code base = no blame model, but devs make mistakes (it’s a
team issue)
-Manage and track code for identification (GIT works as a tool to allow us
to do this) track bugs and look at responsibility
-Success of DevOps (massive applications = massive bugs), multiple
pipelines
-Divide and conquer (specific teams for specific products = develop
separate code and then add it into the main pipeline)
-Appropriate unit testing
-A poor pipeline is worse than no pipeline (work on test cases, commit to
proper testing to stop slow development)
-Regular monitoring of changes
-Azure/AWS
Next week we will look at GIT
The DevOps Way
GIT
-Jenkins
-This is the basis of what we’re doing with the DevOps pipeline
-Looking for events within DevOps pipeline
-Continuous Integration = GIT/Jenkins
Guidelines to Continuous Integration
Guidelines:
-Single source repository = GIT
-Multiple codes stored in a single repository
-Include as much automation as possible in your build
-Compile build along with whole pipeline
-The code will be automatically deployed
-Effective bug identification = a quick fix
-Deployment occurs multiple times a day, then small changes are made to
broken code based on feedback
-Assign team to fix issues
-Development Test and Production Environment (it used to be difficult to
work between both of these)
-EC2 instance machine is exactly the same as production environment (not
quite there yet)
-Shared responsibility model in DevOps
Best Practice for Continuous Integration
Best practice
-Bugs are inevitable but no feedback means less reliability
-Constant monitoring
-Fast fix = cheap fix
-Continuous web application (restricting access means no access for
multiple customers and less revenue for company)
-Commit at least once a day, sometimes a lot more
-Communicate to find out why your feature doesn’t work with someone
else’s (teamwork)
-Even small tasks should be automated as much as possible (manual =
point failure)
-Rollback (use an earlier version of code while fixing issue)
-Security needs to be baked in from the ground up
-Reliability = a team effort
The Benefits of Continuous Integration
Benefits
-Internal team
-Testing coverage (strict processes mean the code is the best it can be)
-Track bugs and see who’s taking responsibility for fixing, who deployed
code, figure out how to fix it (i.e., transparency)
-Continuous feedback from pipeline
-Automation = reliable code
, -Amazon, Google, Netlix (they have rare outages which means more
money for them)
-More responsive to customer feedback (functionality)
-More for less (more money and less effort = better productivity)
The Challenges of Continuous Integration
Challenges
-Difficult to duplicate the same versions, though it is easier now than
previously (duplicate environments in the Cloud)
-Shared code base = no blame model, but devs make mistakes (it’s a
team issue)
-Manage and track code for identification (GIT works as a tool to allow us
to do this) track bugs and look at responsibility
-Success of DevOps (massive applications = massive bugs), multiple
pipelines
-Divide and conquer (specific teams for specific products = develop
separate code and then add it into the main pipeline)
-Appropriate unit testing
-A poor pipeline is worse than no pipeline (work on test cases, commit to
proper testing to stop slow development)
-Regular monitoring of changes
-Azure/AWS
Next week we will look at GIT
