Delivering Software
How to go from woe to go with the Cloud Acceleration Framework, from checking code out of your first repo, to deploying it to Production.
We will start with a high level view so you can see our process and where our products support delivery, and then break it down.
This guide assumes you have set up your machine.
Getting the source
In a modular world it is likely that you will have many repositories. A source control repository represents a something that has its own lifecycle. git repositories are self contained.
To help developers create and share source we use a Projected Monorepo. We recommend an open source tool we developed called Branchout to manage this. It helps us aggregate a number of source folders together, while life cycling them separately.
Branchout is trivial to get all the repositories cloned and ready for use. The result is a consistent layout of source pre-configured to operate with the recommended tooling.
Writing tests
We push testing left as far as possible, writing our tests before our implementation and ensuring code is as of high quality as possible before reaching pipelines. Unit Tests are the first type of testing that can be run against code, and should always be run before pushing a branch for a PR.
Practiv Build also repeats the validation that Unit Testing provides before a trusted artifact is published.
Write your implementation
We’ve done this a lot, and built some great tools to help developers focus, and work faster. Practiv Develop creates a Kubernetes instance on your local machine, and hot reloads your changes every time you hit save, meaning you don’t need to context switch.
Testing and commits
We prefer to commit often, and then raise PRs only when we have value to ship. During this process, we expect your code to pass your tests. Commits should involve conversations with your team, shifting issues left as much as possible so that by the time you raise a pull request, you have minimized the chance of it being rejected as much as possible.
Push and raise PRs
Pushing to a branch in the repo and raising a PR informs others you would like to make a change to the master codebase. On most projects pushing commits to master branch will be prevented for reasons ranging from quality control through to security audits.
By raising a Pull Request you are requesting review. Our definition of done is that you own your code to production, so get it reviewed, then own it all the way through before starting something else.
Approving PRs and Merging
PRs are the way we assure quality, discussion and security. Make sure you understand what the code is doing, if in doubt use walk over and ask.
PR Reviews are super important for quality but they also can’t grind things to a halt. Your review is expected within 15 mins of being assigned, otherwise developers will move onto something else and wipe their hands of the rest of the process to prod.
Practiv Build and Run
Once your repos master branch has the change committed, Practiv Build Jenkins will observe the change and build a new version of the product, environment, Run platform. As this process completes, Keel will update the Kubernetes manifest, and containers running in the namespace, automatically deploying your product and associated applications to the correct environments. You can watch this change occur with Practiv Monitor, a realtime, event driven observability dashboard designed for developers and release managers.
The next guide will cover setting up and using Practiv Build and Run in much more detail.