Michigan IT Symposium 2017 - CI/CD Workflow Tutorial

Editor's Notes

• #2: Let’s get right into it
• #3: I wanted to present a brief primer before we get into the hands on portion. We’re going to go fast and I’m not going to dive deep into certain things for the sake of time. If I had four hours I could go over all of that I’d want. Save questions for the end, and even after the symposium if you have questions or need help or ideas, feel free to email me.
• #4: Been with the University for over ten years Before ARC I built and managed web based systems for Dept of Path I’m one of the luckiest people because my main hobby and passion is also my career My free time is spent playing with and investigating new technology One of the benefits of that is I can then take what I learn and share it I’m very passionate about this sort of things
• #5: And that makes me a pretty good motivational speaker about using technology across many spectrums
• #6: At its core, CI/CD means “dev fast, test fast, push fast, fail fast, rollback fast” By live meaning environments outside a local (laptop) environment. You could be pushing changes to a remote dev or QA environment, and this would still apply. In fact, a common pattern is mirroring branch names to environments. More advanced places provision and destroy entire environments dynamically based on new and deleted branches
• #7: Automation is the primary goal. Take repeatable and necessary tasks and make them part of your development process. Remove the need to SSH to a server. Install a service. Run a database script. Remove the fear that a code change will break your application
• #8: I know this is a very big change for most people. Especially larger institutions.
• #9: It can also be scary. It’s a lot to learn, it’s a different way of thinking. It’s also giving up a lot of control. This can be frightening.
• #10: This can also be the single biggest value added change you could implement. This increases overall productivity, alleviates stress, and if you’re a development nerd like me, is SUPER fun.
• #11: This is the circle of life. Dev. Test. Push. Repeat. It’s a constant cycle. Some of these stages you might not think apply, but they should. Here’s a more practical look
• #12: Asterisk one: Tests come in a variety of shapes, sizes, and stages. A test could be a unit test, deploying a short lived instance and running practical tests. Asterisk two: Deployments also come in a variety of shapes and sizes. Deploy could mean changing code on a server. Spinning up a new docker container. Or pushing a new android and ios build up to the store. Verifying deployment is just another safeguard or test. It could be part of the CI build checking logs, polling a health check, or as simple as a bash script checking for an open port. CI/CD should really be CI/CD/CF. You want constant feedback.
• #13: Part of this transition to automation involves having good tests. Yes, seeing if a port opens is a test in a pinch, or asserting 1+1=2. But the more you can test, and verify your tests, the fewer bugs will come up.  The safer you’ll feel every time you make a change.
• #14: With this paradigm of pushing small and pushing fast, your changes should apply faster. Also, if one of your many feedback mechanisms shows a problem, you can rollback faster. Just as much as building automated tests, you need to build automated rollbacks as part of your deployments. Yet again though, this is a case of “It depends on your actual use case”Mo
• #17: I think there are three big pools that people fall into these days.
• #18: Get your database schema into your SCM. Bundle tests into it. Always have a rollback plan. Test. Your. UI. I cannot stress this enough. There is an abundance of tools out that can do it for every platform. When I say test your application, most people will think I mean Unit Tests. I mean unit tests and more. Another test? Security scan. Sure the code might run but you also might have deployed something vulnerable. Lots of scanners these days have APIs that you can use to trigger new scans if it’s a security appliance. It depends on your environment and your project.
• #19: Common things are common. Automatically test against multiple versions of Android and iOS. Even run UI tests against different emulated hardware. Automatically. After that, you can push the new build up to Android/iOS and immediately start a staggered rollout. Luckily with mobile apps, rollbacks are easy and you get crash reports. Constant Feedback.
• #20: Common problem with config management? Simple syntax errors. Lint your files ahead of time. At this point you’re already trusting services to push infrastructure changes. Remove the commands you run by hand and automate the deployments. Build functional tests to ensure your changes applied correctly and if not: ROLLBACK
• #21: If it feels like I’m repeating myself, I am. A lot of these concepts are common across any project. The devil’s in the details but the desired structure stays static.
• #22: You have to start somewhere. And again, it depends. If you take something away from these slides let it be UI Testing should not be overlooked or ignored. Ultimately some testing is better than none, but (again repeating myself) You’re only as good as your tests. And the more tests you build the better and safer you are.
• #23: I could come up with endless reasons but here are just a few for why this is important. 
• #24: I cannot stress this enough. Adopt this mantra. This isn’t just for CI/CD. This is for everything.
• #38: There are patterns. Surprise!