philosophies, practices, and tools that increases an organization’s ability to deliver applications and services at high velocity: evolving and improving products at a faster pace than organizations using traditional software development and infrastructure management processes. This speed enables organizations to better serve their customers and compete more effectively in the market. - AWS
for a release to production Deploy changes to testing or staging or production environment Developers will always have a deployment-ready build artifact that has passed through all testing process
in its own process and communicates with other services through a well-defined interface (HTTP, GRPC, Queues) Deployed independently or grouped with similar services
and software development techniques Treat infrastructures like application code Since it’s like code, it can be deployed with standard patterns, updated with latest versions and patches
application and infrastructure performance impacts end user experience Alerts and continuous monitoring helps to respond to incidents effectively Gives a continuous feedback to evolve business logic
together to deliver features Use of chat, issue tracker and wikis speeds up the communication among devs Makes other teams like sales and marketing to align more closely on goals and projects
out a ‘feature’ branch from ‘dev’ branch. After implementing one of the feature, write unit test cases and merge it back to ‘dev’ branch. Then, delete the ‘feature’ branch. Our CI system kicks off as code is pushed to ‘dev', runs tests and deploys it in the dev server(?) Once all the features for the currents sprint are done, After a quick code review we merge dev to master. The CI system will kick off, builds and deploys the code pushed to master in prod machines Repeat the steps for every sprint in JIRA
will always be locked, one cannot directly work on master branch. You can work by only branching out. The tip of the master will always be the latest, stable, production release. Refer Semantic Versioning for versioning your releases: https://semver.org/
prod systems. If an unknown bug makes v0.2 unstable, we can quickly rollback to v0.1while fixing bug in v0.2. When rolled back client may lose the new features of v0.2 but they won’t experience total downtime as it’s rolled back to working version v0.1. Once bug in v0.2 is fixed, it's deployed again
to ‘dev’ from ‘feature' branch Unit test cases helps us to check the sanity of every function in the code. So, any function in the code should have only one responsibility. Unit test cases are important while setting up CI/CD. Since every feature is continuously deployed by the system, code should be well tested before pushing to master branch
provide some way to give the insights while running A very simple way to do it is having a basic logging system dumping logs to files. In future we will see how we can create a dedicated logging mircorservice that collects logs from other services and provide application and business insights.
dudewhocode
watabee
nobu74658
komakichi
l2hyunwoo
akidon0000
ike002jp
nealle
vinistock
sasagar
shota_tech
medley
chrislema
bkeepers
philnash
mclloyd
pedronauck
chriscoyier
sstephenson
samanthasiow
bryan
bluesmoon
matthewcrist
destraynor
