currently work as a Lead Enterprise Architect at TWINT • During the last ca. 25 years I worked all over the world for companies and customers in various fields of business and technologies • I am an ISAQB Instructor and love to talk about software architecture
smaller your company, the more likely you already do DevOps and/or need DevOps • DevOps is more than just pipeline creation… • It is a mindset which needs to start already at planning phase and live throughout the whole process until operations • It covers aspects of infrastructure setup, development process, logging / tracing, deployment and observability
Manual setup and documentation may sound like a fast and simple idea… • But when “in the setup flow”, we often forget to document tweaks we did… • With portal setup we also do not have any version history… • And setting up int, prod, dev… requires us to repeat the setup manually again and again..
a bit more time to set up… • But once it is setup, you can easily deploy a new environment by simply switching the configuration values and redeploy • As it runs on code files in text form, you can version it like any other code in a repository and exactly redeploy a given state. • Changing infrastructure decisions are not effort-free but much less error-prone and much faster than manual portal setup
(https://opentofu.org/) • TerraForm – an IaC Framework from Hashicorp (https://www.terraform.io/) • Pulumi – an IaC Framework based on popular programming languages (https://www.pulumi.com/) • Ansible - an IaC Framework by RedHat (https://www.ansible.com/) • Puppet – an IaC Framwork (https://www.puppet.com/)
devs are seniors… • It takes too much time…we need to develop features fast to stay up to date… • Too many false positives…our business seems too complex for this… • People in our team do not like each other, and thus use the process as leverage.
mistakes… • An extra layer of security is always good • The rules in the automatized quality assurance process are objective • Code artefacts are guaranteed to have a certain quality, style and test coverage
Prettier while you code. • Use a linter while you code (and do not ignore its output) • Write tests. • Use a version control for your code and use pull requests to merge changes. • Check your code for leaked keys with e.g. GitLeaks • Run a Static Code Analysis tool over your code (e.g. Sonarcube or KICS) and have it break the build on non compliance • (verify the architecure with an analysis tool) • Check your dependencies for vulnerabilities • Perform a human code review with a colleague before merging the code
• Linters for your IDE • Sonarlint(https://www.sonarsource.com/products/sonarlint/) • SpotBugs (https://spotbugs.github.io/) • ESLint (https://eslint.org/) • … and many more • Static Code Analysis Tools • KICS (https://kics.io/index.html) • Sonarqube (https://www.sonarsource.com/products/sonarqube/) • GitLeaks (https://gitleaks.io/) • ArchUnit (https://www.archunit.org/) • … and many more • Dependency Scan • Snyk (https://snyk.io/) • Blackduck (https://www.synopsys.com/software-integrity/security-testing/software-composition-analysis.html) • … and many more
than just a pipeline to build and copy code. • It executes and documents a process of gates you want to pass, before your code goes live • Usually, it contains your automated QA pipeline (This can include test runs, security checks, secret injection and others) • It ensures that your code passed all those gates and is per definition a shippable increment that can be deployed.
copy files from A to B • CD or AD (automated deployment) ensures that a deployment of a code that passed the CI stage is repeatedly executed in exactly the same way over and over. • CD also can inject secret information you do not necessarily want everyone in the company to know and use deployment accounts you do not want to share publicly with everyone. • CD also can define rollback scenarios in case that a deployment fails. • You get a detailed log about what steps were performed when. (in case of necessary debugging or legal actions)
hardware or ressources that can break or have issues. • It can also be your code generates side effects, has performance issues, startup problems etc. • During operations it can also be that a vulnerability in one of your dependencies is detected. • …
critical thresholds which trigger alarms. • Define performance KPIs of your APIs (e.g. response time, error states per time, heartbeats…) • Log moderate, make sure the log entries help you in case of issues. • Use different log levels not to dig through millions of log messages (or think about emoticons) • Use vulnerability scan services also after you deployed your software! • Create dashboards for your teams AND MAKE SURE TO ALSO WATCH THEM
big corporate but also for small startups • Think about DevOps already in the planning phase of your project or software product • Automatize the setup of your infrastructure • Define and enforce a quality assurance process • Use CI/CD to verify and deploy your code (also for interpreted languages!) • Setup observability tools and dashboards to proactively monitor and adjust your software for a smooth operations process.
janmoser
shonansurvivors
sdosamut
sansan33
gotalab555
bethany
kurochan
aeciopires
ivry_presentationmaterials
ditccsugii
cdataj
yahonda
destraynor
vanstee
addyosmani
holman
jakevdp
eileencodes
paigeccino
rmw
tammyeverts
michaelherold
