- \n
- Linting and Formatting<\/li>\n\n\n\n
- Unit Tests with Code Coverage<\/li>\n\n\n\n
- Security Scanning for potential vulnerabilities<\/li>\n\n\n\n
- Building the source code<\/li>\n\n\n\n
- Deploying the build to a non-production environment for integration tests<\/li>\n<\/ul>\n<\/blockquote>\n\n\n\n
Before we dive into these steps, let’s briefly discuss our branching \/ release strategy. The most common strategies are GitFlow, Github flow, Trunk based, Gitlab flow, and variations of each. For the majority of my projects I prefer a trunk-based strategy with small, frequent updates to my main production branch. <\/p>\n\n\n\n
A typical change in the production source code starts with pulling down
main<\/code> and creating a new branch. Let’s call the new branchfeature-request-1<\/code>. I’ll make my changes to the source code in this branch and when I am ready for the code to be merged intomain<\/code>, I will submit a pull request. <\/p>\n\n\n\nThe pull-request to
main<\/code> is an event in Github actions that we will use to trigger a series of steps in our python workflow. <\/p>\n\n\n\nStep 1.<\/strong> Lint and Format our code using pylint and black. This will make our code easy to read in a standard format and also check for syntax errors. <\/code><\/pre>\n\n\n\nStep 2.<\/strong> Run our unit tests. As a rule of thumb, I strive for 80% of my code to have test coverage. It's not always feasible with large codebases, however greater coverage ensures the code is functioning as intended. <\/code><\/pre>\n\n\n\nStep 3.<\/strong> Security scanning using Github or other 3rd party tools to find any vulnerabilities in the code before we build. It's a good idea to fail the CI process here if the number of vulnerabilities exceed a defined threshold. <\/code><\/pre>\n\n\n\nStep 4.<\/strong> Execute the python build process to build our source package. I prefer using the Github Commit SHA as the version number. This is achieved by updating the pyproject.toml<\/span> file with dynamic versioning using setuptools-scm<\/a><\/code><\/pre>\n\n\n\nStep 5.<\/strong> Deploy our source code package to our Development environment for further testing. Once deployed, pull request reviewers (other team members) can run integration tests to validate the integrity of the code before approving and merging into the main<\/span> branch. <\/code><\/pre>\n\n\n\nWe can chain these jobs sequentially or have them execute independently. It’s also a good practice to write the results of these jobs as a comment on the pull request so that other code reviewers or approvers can quickly see that these jobs have succeeded before reviewing the code itself. The pull request can be rejected if our jobs fail, saving time for those required to review. <\/p>\n\n\n\n
Artifacts<\/h3>\n\n\n\n
Python packages can be stored as GitHub artifacts and used in subsequent jobs. <\/p>\n\n\n\n
Python build packages are initially created with the Commit SHA as the version to quickly identify each package with a specific commit. Release versions will be built using tags created with semantic versioning. <\/p>\n\n\n\n
\n
Github Packages does not support PyPi repositories, therefore I use AWS CodeArtifact since most of my projects are deployed in AWS.<\/p>\n<\/blockquote>\n\n\n\n
Release Process<\/h3>\n\n\n\n
Once the pull request is approved and the commit is merged into
main<\/code>, at this point it’s ready for a Release. <\/p>\n\n\n\nThe source of the release is
main<\/strong><\/code> and a new tag with semantic version format(v.0.0.1<\/code>) is created. <\/p>\n\n\n\nRelease notes are added and the repository is tagged, then bundled as a tarball (in this case). The python package is rebuilt using the v0.0.1 tag as the version and then deployed to the Development environment followed by Production. <\/p>\n\n\n\n
![\"\"](\"https:\/\/platformdev.org\/wp-content\/uploads\/2024\/09\/image-1024x625.png\")
<\/figure>\n\n\n\nFor more information, including some sample workflows please see the link below. <\/p>\n\n\n\n
Sample Reusable Workflows:<\/p>\n\n\n\n