Forem: Tania Allard

Contributing to open source projects: contributors etiquette

Tania Allard — Thu, 08 Oct 2020 12:25:49 +0000

Welcome to the second article in the "Contributing to Open Source" series.
In the previous post I covered some of the benefits of contributing to open source as well as some guidance on how to find projects and items (or issues) to work on.

Open-source brings together people from all over the world to collaborate and find solutions to complex problems.
This post aims to help you improve your communication and collaboration skills. And at the same time, help make our community friendlier and safe for us all.

Communication and people skills

I have been contributing to open source for some years now, mainly because I love writing code and the communities I belong to. Over these years, I have had a mix of experiences and challenges. And in both cases, maintainers and fellow contributors have played a massive role in this.

These are my top recommendations when it comes to communicating and collaborating with other folks or projects:

First thing first - before opening an issue, creating a Pull Request familiarise yourself with the project's Contribution Guidelines and their Code of Conduct. Make sure you know what the existing communication channels are and use them accordingly (e.g. Gitter, Slack, Github issues, Discourse). Read the documentation first - sometimes the answer is in the documentation. Go through the documentation and see if you can find an answer to your question.
Before opening a new issue, make sure to check the existing ones, so you do not open a duplicate. If there is an open issue tackling the same problem you are reporting comment on it providing additional context. If there are issues that are related, make sure to reference them in your newly created issue. Pro tip: avoid the urge of asking: why has this not been fixed yet? Or similar.
If you open an issue that you are not able to resolve yourself, please add a note about this. That way, maintainers can label this issue accordingly (e.g. "help wanted", "needs discussion"). If possible work on a reduced test case.
When reporting issues or requesting features, please use the project's issue tracker. This allows for discussions to be open and visible to the broader community. Do not request features or raise issues by emailing/sending Twitter DMs to the maintainers.
Keep your communications smart:
- Only comment if you have something to add to the discussion.
- Always provide context - I mentioned this before but minimise the cognitive burden on maintainers and contributors by absorbing the complexity on their behalf. Make it explicit what is being asked of them.
Respect people's time - everyone has other responsibilities and need time to unwind and recharge their batteries. Do not ask maintainers for an ETA or ask them to prioritise your issue. Sometimes issues go silent for a while (as PRs do) so if needed make use of a gentle "bump". This is asking for concrete actions in a respectful manner. "Do you have a couple of minutes to look at this PR?", "I am having trouble with this test - do you have any pointers on what I might have missed?".
Avoid shaming/guilting - sometimes your PR will not align with the project's roadmap, others your feature request might not be relevant, or the extra effort might not outweigh the benefits. You might not get an immediate response because sometimes maintainers are overworked and burned out. Remember: folks often work on open source voluntarily. Public shaming them for not having X feature, pointing out how this other project is much better than this one or "how bad their API decisions are" does not benefit anyone. Be gracious and thank folks for their work, avoid sending emails or start Twitter rages when you are frustrated and cannot solve your issues. Instead, consider contributing your solution (when you get there) and move on.
Avoid entitlement - always be respectful when providing feedback or suggestions. If there is something that could be improved and you can help with this, offer your help.
Don't be a bystander - have you noticed something that is in clear breach of the Code of Conduct? Report this immediately so that maintainers can take care of this situation. Disagreements can quickly escalate into very nasty problems, so the best you can do here is bring it to the attention of the core developers as soon as possible.
Avoid unnecessary discussions - maybe folks have decided to adopt a specific style guide or use a code formatter. Though this might not align with your personal preferences, avoid the urge to convince folks on why they should change their style guide.

Workflow ettiquete

The next thing we can improve is our etiquette around the contribution itself:

If the project has issues or Pull Request templates, please USE THEM. If it does not provide as much information as possible to help the maintainers and contributors:
- Issues: steps to reproduce the problem, details about your environment and OS, any steps you tried to fix the issue, command line outputs and/or screenshots are great additions too. If you have suggestions on how to solve this problem, make sure to add them also.
- Pull Request: what issue the PR relates to (use fixes/closes: ), what you did and how you tested your changes. Also, note if this introduces braking changes or requires dependencies upgrades. Make sure to also update the docs and add a note about this. If adding a new feature, make sure to add the relevant tests or edit existing ones.
- Feature request: though this is usually raised as an issue make sure to provide enough context about WHY this feature might be useful for the community (rather than only yourself). If you have ideas on how this could be implemented or what skills would be needed, make sure to point it out. Pro tip: avoid asking questions like "Why does this do not exist already?"
Ask for feedback early - as soon as you start working on a fix or feature create a PR and mark it as Work in Progress (WIP) on the title. If you get feedback early, it will be easier to align your work with the project vision, and you can ensure your PR will be merged.
Use descriptive commit messages - "Fixes issue" does not provide context nor describe what you did "Ensure the correct variable is referenced" is a much better message.
One issue one PR - make sure that your Pull Request tackles one single issue. This makes it easier for others to review your work and provide feedback. It also makes it easier to keep changelogs consistent.
As soon as you decide to work on an issue, make sure to explicitly say you will work on it. This helps others to know what issues are actively being worked on without stepping on each others' toes.
Familiarise with Gitflow and/or with the contribution guidelines for the project.
Ask first - if you are planning to submit a huge PR to a project to which you do not contribute regularly, ask the maintainers first. Make sure that what you are planning to do aligns with their project roadmap or vision. If this can be split in smaller PR's, make sure to do this.

That is all for now. Do you have any other suggestions I missed in here? Make sure to add them to the comments.

And keep your eyes peeled for the third post on this series "What makes a good and meaningful contribution to open source projects?".

Contributing to open source projects: let's get us all started

Tania Allard — Mon, 28 Sep 2020 17:50:35 +0000

Have you always wanted to contribute to Open Source but do not know how to get started? Are you preparing to participate in Hacktoberfest? Well, look no more, because in these series you will learn how to do your first contribution to open source.

In this first part of the series, we will cover:

Motivations to contribute to Open Source
How to get started with your contributions
What to look for in an Open Source project
Getting ready to contribute

Why contributing to open source?

I am a long-time open source user and contributor. So much of my work relies on open-source software. Also, belonging to open source communities has definitely opened many doors and opportunities for me in the past. Some reasons you might want to contribute to open source are:

It can be a rewarding experience: knowing that you helped fix a pesky issue or improve the documentation for the libraries that you use can be quite satisfying and benefit a bunch of folks.
It is an excellent way to learn new skills: from improving your version control skills to working collaboratively with other developers, technical writers and designers, you always acquire new skills (or sharpen your existing ones).
Being part of the community: contributing to open source helps you build relationships within the open-source community
Find mentors and mentor others: as you work on open source projects you often need to explain how you do things and discuss the best solution to a problem.
Going beyond the technical skills: not only it allows you to improve your coding or technical skills, but it also allows you to work on essential people skills such as effective communication, conflict resolution, leadership and organisational skills.
Working in the open: in many cases, we do not get the chance to share what we work on in our day job due to NDIs or other circumstances. Or maybe you are looking for a career change and want to build an online developer presence. Contributing to open-source gives you a chance to showcase all of the skills mentioned above in an open and public manner.

How to get started with open-source contributions

Right, so far, I only focused on the "why you might want to contribute to open source". Contributing to open-source can be pretty daunting, mostly if you have never done it before.
And to be accurate, there are many steps involved, from choosing the best project to contribute to, selecting an item to work on to submitting your contribution.

So let's break this into smaller pieces.

Finding the right project

The most straightforward way to find a project is thinking about the libraries you use regularly. And head over to the project's repository.

Some items are a good indicator that the project is welcoming and accepting contributions. Head over to the project's repository and look for:

License: make sure the project has an open source license, if you cannot find this, then the project is not open source. This should be as a LICENSE file in the repository.
Contribution guidelines: if the project repository is in GitHub, look for a CONTRIBUTING.md file. This should either contain the detailed process to set your development environment, how to run the tests and build the documentation. As well as any conventions for submitting contributions.
Code of conduct: having a Code of Conduct is critical to keep the community interactions safe and friendly for us all. It helps set ground rules for contributor's behaviours and also outlines mechanisms to report violations to these rules. Having a CoC is a good signal towards a project being inclusive and welcoming. But make sure there are also channels to report CoC violations.
Communication channels: some projects will have mailing lists for folks to ask questions and receive guidance. Others have Discourse servers, Gitter or Slack channels. Keep track of these resources as you might need them to ask questions.
Contribution workflow: check the number of issues open, Pull Requests and check the flow of discussions on issues. Spending some time doing this can be super valuable to get an idea about maintainers-contributors interactions.

Finding something to work on

This is perhaps one of the most challenging parts of submitting your first (or hundredth) contribution. But here are my top tips:

Think beyond code: there are so many ways in which you can contribute to open source, apart from code. I often get folks asking me "I am not a developer but a technical writer/designer/else, can I still contribute?" and the answer is yes. The truth is open-source can significantly benefit from a diverse set of contributions, so make sure to think outside the coding box and think about how you can use other skills. Do you like organising events? Are you a great graphic designer? Are you an accessibility expert? Do you speak multiple languages? Think about how you can add value to the project while building on your skills and interests.
Build from experience: if you are contributing to a project, you have used before you might have encountered something that could be better. Maybe the instructions for setting up your development environment are outdated. Perhaps some of their tutorials are not clear enough. Use this to your advantage - having a fresh set of eyes can be massively helpful to improve the contributor's experience.
No contribution is too small: maybe you encountered a broken link in the documentation or the project Readme, consider submitting this as a contribution.
Finding issues to work on: There are multiple ways in which you can find issues to work on. For projects on GitHub, you can head over to their Issues page and find issues marked as help-wanted, beginner-friendly or good first issue.

Something quite nifty I found about recently is that you can directly head over to the issues marked with these labels directly by going to the projects contributing page. For example, for JupyterHub, you would head over to https://github.com/jupyterhub/jupyterhub/contribute. Plus the Contribution guidelines are also made visible so you can access them directly!

Beginners issues aggregators: there are some sites that you can use to find beginner-friendly issues across many repositories, programming languages and organisations.
- GitHub explore
- First Timers Only
- Up for grabs
- Good first issues
- First contributions
- Code Triage this allows you to subscribe to your favourite project and get a new issue in your inbox for triaging

You are almost ready!

Before getting working on an issue, make sure to have a quick check to make sure that nobody is working on this item already.

Go to the issue and express your intention to work on it so that there is no duplication of effort

Sometimes folks commit to working on an issue, but it turns out they did not follow through (maybe their circumstances changed, I have been there, and it's ok).

Head to the issue and say you would like to follow on it. Ask questions if you need to clarify any points or discuss implementations.

If there are no issues opened for the item, you plan to work on open an issue straight away and discuss the idea.

Provide enough context, links and screenshots if this help support your issue.

Next steps

Hopefully, this will get you all started. If you want to get some practice on creating Pull Requests this resource by @kentcdodds is great. You can also make a PR to the First Contribution repository to get some hands-on experience.

Do you have any tops tips to get started? Add them as comments to this article, share your favourite projects to contribute to or examples to outstanding Readmes.

And do not miss the following articles in the series where we will discuss PR etiquette and efficient communication and contribution workflows.

10 top tips for reproducible Machine Learning

Tania Allard — Fri, 24 Apr 2020 13:59:34 +0000

10 practical tips for reproducible Machine Learning

The one where you get some advice to make your workflows more reproducible

The boom of Machine Learning and AI solutions is undeniable. We have "AI" enabled everything: from medical diagnosis optimisation to HR and beer brewing processes.
But thanks to this boom, we have also realised that developing and productising such products is hard, really hard. And it was not long before we started seeing these kinds of articles popping, well, everywhere:

https://www.wired.com/story/artificial-intelligence-confronts-reproducibility-crisis/ Hutson M., Science Magazine Feb 2018, Vol. 359 pp. 725

What is reproducibility, and why do we care?

A result is reproducible when the same analysis steps performed on the same dataset consistently produces the same answer.
Reproducible Machine Learning can avoid significant errors and costs in the future. As well as making it easier to track and explain the insights/predictions generated.

But beyond that, working reproducibly facilitates collaboration and review processes, ensures continuity of your work and retains institutional knowledge and future proofs your work. This is extremely important because most of the time, we do not work alone but with a group of data scientists, software engineers and many other stakeholders.

The truth is that reproducibility in Machine Learning is a problem that every practitioner faces daily.

Have you ever found yourself wondering any of the following?:

What version of the dataset was used to train this algorithm?
What version of the algorithm/model do we have in R&D/staging/production/was published in the paper?
Did we keep track of all the parameters and features we explored and the baseline models?

Photo by Paolo Nicolello on Unsplash

We have all been there, trust me.

So without further ado, let's dive into how to make your workflows more reproducible.

0. Identifying the key players

The base for reproducible workflows lies in being able to track and reproduce your data, computational environment and code.
So you will notice that most of the recommendations here centre around these three critical assets:

I am not going to dive too much into this (as this deserves a whole post for itself). But, you ideally want to make all your work reproducibility across three levels:

Methodology: for example, how your formulate your experiments and prove or disprove your hypothesis.
Model/algorithm (though Machine Learning goes way beyond models that get deployed). For example, explain the complexity of your algorithm and the space you are covering how were your hyperparameters chosen.
Infrastructure: here you want to ensure that there are a robust infrastructure folk others to access your data and run your code. Make sure also to describe the hardware you used (i.e. GPU).

1. Always know what you are expecting from your data.

We all know how vital good quality data is for good quality and reliable Machine Learning. So we always should know what we are expecting from our data at all times - what types, distributions, ranges and schemas.

One of my favourite tools to do this is Great expectations as it integrates with other tools I use like Spark, Airflow, Jupyter Notebooks and pandas (among others). It is an excellent tool for data validation, testing and documentation.

For example, if you have a raw data source on which you do some manipulation before storing it in a database, you can add multiple validation steps for your input and output data.

If you are collecting data from third-party APIs, you can use JSON schema to validate against the meta schema.

2. Develop pipelines.

The best way to keep track of all your outputs, inputs, metrics, models and data even before using specialised tools is being able to keep track of each task you are performing.

Many tools allow you to build robust pipelines. Many of which revolve around the concept of Directed acyclic graphs. Some of my favourites are:

Dagster: I have found that it is super easy to use and has native Jupyter integration (win!).
Airflow: this Apache incubator project has gained loads of popularity. The UI makes it very easy to have an overview of your DAGs and their statuses.

These add a lot more complexity:

Pachyderm: A Kubernetes native platform for repeatable data science.
Kubeflow

However, you decide to implement your pipelines keep this rule of thumb in mind:

✨ Top tip: Split your tasks into atomic units of work. Where each node of your DAG or each step in your pipeline does one single task.

This helps avoid the "Change anything Change everything" (Scully et all) problem.

3. ML loves randomness - deal with it.

There is randomness everywhere:

Random initialisations
Random augmentations
Random noise introductions
Data shuffles

The sound advice that you will find everywhere is always set and save your seed.

If working with Python, you should often find yourself performing a version of this ritual:

import os 
import tensorflow 
import numpy 

os.environ['PYTHONHASHSEED'] = str(seed)

random.seed(seed)

tensorflow.random.set_seed(seed)
numpy.random.seed(seed)
tensorflow.keras.layers.Dropout(x, seed=SEED)
tensorflow.image.random_flip_left_right(x, seed=seed)
tensorflow.random_normal_initializer(x, y, seed=seed)

Another source of randomness is - data! When we split the data for training and validation, we often use different splits.

The solution: fix train and validation splits before training - if using methods like test_split_train from scikit-learn make sure also to specify the seed argument.

4. Hyperparameters everywhere

Finding the right hyperparameters for your models can be quite an involved process. These can be particularly problematic when you are running multiple experiments with different network architectures.

✨ Top tip: As a rule of thumb: not only keep track of the parameters but also of the output metrics of each model associated and your selection process/baseline.

An excellent example of how to keep track of your hyperparameters in a sane manner can be found in the Pachyderm distributed hyperparameter tuning sample.

The use of pipelines to split, train, test, and select the models and hyperparameter makes it so much easier to keep track of the outputs at all stages as well as reporting on the rationale behind why you chose specific hyperparameters.

5. & 6. Version control & data decoupling.

How often have you worked on pieces of code that had lines like this:

import pandas as pd

df = pd.read_csv("../../../data.csv")

In this scenario, both data and code are tightly coupled. To ensure reproducibility, you want to keep track of both your code and your data versions. Not only for the final outputs but also the intermediate results.

Imagine you have a workflow like this:

Although this is a somewhat simplified pipeline, there are still multiple outputs which you want to track (data, code and serialised files).

A great tool for this is dvc - which allows you to keep track of all your assets with Git without * storing your data in Git*.
This allows you to decouple data and code and their respective versions to ensure reproducibility:

7. Testing

Testing in Machine Learning can be quite complex. Again, I am not going to dive too much into this as testing strategies deserve a post for itself. So here is a checklist of testing strategies and items you need to consider testing:

API calls and contract tests against your data schemas
Integration tests for your pipelines
Regression tests
Unit tests - test your methods, transformations
Test that model weights and outputs are numerically stable
Reproducibility across environments: development, staging and production. The predictions across these should be the same.

✨ Top tip: A package I find using over and over again is Hypothesis for property-based testing. It not only has simplified my testing strategies but also has increased my confidence in the tests.

There are extensions to Hypothesis which are worth checking: https://hypothesis.readthedocs.io/en/latest/strategies.html.

8. Reproducible environments

For a piece of work to be reproducible, the computational environment that it was conducted in must be captured so that others can replicate it.

Many tools allow you to create reproducible environments or at least to get close to.

Depending on the projects I am working on, I tend to mix some of these tools:

And I am still a fan of Make because it is fantastic.

✨ Top tips:

There is no one size fits all. Choose the most appropriate method for your project for capturing your computational environment
Capture your computational environment - I recommend not only pinning the main dependencies but also the sub dependencies and use a tool with dependency resolutions (pip-tools, pipenv and Poetry are proper tools to do this)
Share your captured computational environment along with your code and data if possible

9. Automate

A lot of errors can be introduced when we depend too much on the human-in-the loop for our workflows.
So whenever possible automate stuff not only, it will save you time but will optimise your workflows and increase your confidence.

Some great tools I use for automation are:

Tox - for automated testing
Nox - flexible test automation
Invoke - general-purpose task execution (quite similar to Make but Python-specific)
Repo2docker - create Docker containers from GitHub repositories
Binder - create reproducible interactive environments from GitHub repositories
GitHub actions - Continuous integration and devliery as well as workflow automation

✨ Top tip: Start automating the most critical parts - deployment, container creation, testing and move from there.

10. Consistency and standards

With the myriad of tools and workflows out there there is not a single solution for the reproducibility problem.

But what I have found is that consistency is critical. Here are my last ✨ Top tips:

Have a consistent project structure. You can use tools like data science cookiecutter.
Adhere to coding standards:
- Use a fomatter and linter. I normally use black, pylint, and flake8 as well as isort.
- Using these tools helps me with code quality.
Document and documentation as code.
- Many folks do not enjoy writing documentation. But something I started doing a while ago is treating docs as code (well almost). I build all my docs through my continuous integration pipelines, and I also run tests on them.
Choosing tools:
- I have mentioned many tools here. But each of them come with a learning curve and tricks you have to learn. Chose what works for you and learn it well, rather than trying to learn how to use all the tools.

That is it! These are some practical tips to get you started with Reproducible Machine Learning.

Do you have any other tips I missed? Let me know in the comments.

You can also find me at:

💻🚀 Tech bites: What is the cloud?

Tania Allard — Wed, 08 Apr 2020 09:17:23 +0000

These days everything is on the cloud - but what is this so called "cloud"? This infographic aims to help you all learn more about how the cloud works and what it is.

You can find the pdf version here which is released under CC-BY.

✨ This post is part of a series of visuals I will be working on over the next few months so I will be adding al the visuals to this GitHub repository

trallard / tech-bites

💻🎨 Infographics, digital assets and others to explain tech concepts, tools and techniques!

What is in here?

The digital assets for the series of infographics I produce. The goal of these is to provide insight on tech, tools, and techniques in easy to digest formats.

Infographics table of content

All of the content will be released both in English and Spanish and you can find it here:

🇬🇧 English version
- Serverless 101
- Cloud 101
🇲🇽 Spanish version
- Informática sin servidor 101
- La nube 101

✨🙋🏻‍♀️ Want to translate into other languages? Let me know!

🙌🏼 Contributing

If you want to suggets a topic to make an infographic on please use the new topic template in this repo issues ✨.

You can find the contributing guidelines here.

We are now accepting translations. Please check the contributing guidelines first and then use the translation template in this repo issues. 🌎🌍🌏

📝 Further resources

☁️ Azure fundamentals interactive tutorial
⚡️…

View on GitHub

💻🚀 Tech bites: What is serverless?

Tania Allard — Tue, 07 Apr 2020 15:16:34 +0000

Serverless computing has gained a lot of traction recently. But, are you still trying to wrap your head around how this works?
Wonder no more, I created this infographic as a gentle 101 (introductory) resource to serverless computing.

You can find the pdf version here which is released under CC-BY.

✨ This post is part of a series of visuals I will be working on over the next few months so I will be adding al the visuals to this GitHub repository

trallard / tech-bites

💻🎨 Infographics, digital assets and others to explain tech concepts, tools and techniques!

What is in here?

The digital assets for the series of infographics I produce. The goal of these is to provide insight on tech, tools, and techniques in easy to digest formats.

Infographics table of content

All of the content will be released both in English and Spanish and you can find it here:

🇬🇧 English version
- Serverless 101
- Cloud 101
🇲🇽 Spanish version
- Informática sin servidor 101
- La nube 101

✨🙋🏻‍♀️ Want to translate into other languages? Let me know!

🙌🏼 Contributing

If you want to suggets a topic to make an infographic on please use the new topic template in this repo issues ✨.

You can find the contributing guidelines here.

We are now accepting translations. Please check the contributing guidelines first and then use the translation template in this repo issues. 🌎🌍🌏

📝 Further resources

☁️ Azure fundamentals interactive tutorial
⚡️…

View on GitHub

Let the posadas begin - Day 16 of the #25DaysOfServerles challenge

Tania Allard — Tue, 17 Dec 2019 12:00:17 +0000

This article is part of #25DaysOfServerless. New challenges will be published every day from Microsoft Cloud Advocates throughout the month of December. Find out more about how Microsoft Azure enables your Serverless functions.

Have an idea or a solution? Share your thoughts on Twitter!

It's the 16th of December, which can only mean one thing: Posadas are finally starting in Mexico! Everyone is already preparing for the following nine days of posadas and deciding on venues all across Mexico City for this festive tradition.

A couple of months back, Xanath offered to put together a list of hosts and locations so that all her friends and family had the details for each posada. With all the servers missing and so little time to collect the sites and inform everyone Xanath has asked some friends for help.
They will all be working together to make a solution to help folks to find the location of the next posada.

The challenge

Your challenge is to create a simple solution for Xanath's friends and family to find the locations of the upcoming posadas as well as the name of the person hosting.
Since there will be several people working on the project and adding locations at the same time, you need to make sure that the solution is accordingly updated and deploy to reflect these changes.

Tips:

To allow for the solution and data to be updated as fast as possible, the deployment should be made automatically after a Pull Request has been merged. You can achieve this using services like GitHub Actions or Azure Pipelines.
You can specify the locations in any way you prefer (i.e. addresses, latitude and longitude pairs). Still, you need to make sure that every place added adheres to the same format.
There are many ways in which you can implement this solution; we recommend you start with a simple one, implement your CI/CD pipeline and refine later.

A solution

In this particular challenge, the main focus is setting up a CI/CD pipeline for an Azure Function, so I decided to use Python for this challenge.
Since the main focus is not the function itself, I am going to summarise the process quite a bit. Still, you can follow this tutorial in case you want a step-by-step guide on how to create an Http Triggered Azure Function in Python.

I used VS Code and the Azure functions extension to create a Python Http triggered function with the predefined templates as the starting point.

The next step is to decide on the format for the locations for the challenge. In my case, I created a locations.json file which looks something like this:

{
 "locations": [
    {
       "name": "Bellas Artes",
       "date": "December 16, 2019",
       "host": "Tania Allard",
       "type": "geopoint",
       "location": {
       "lon": 19.4352,
       "lat": 99.1412
       }
    },
    {
       "name": "Museo de Antropologia",
       "date": "December 17, 2019",
       "host": "Tania Allard",
       "type": "geopoint",
       "location": {
       "lon": 19.4260,
       "lat": 99.1863
       }
    }
 ]
}

And I modified the __init__.py script accordingly:

import datetime
import json
import logging
from pathlib import Path

import azure.functions as func


def main(req: func.HttpRequest) -> func.HttpResponse:
 logging.info("Someone is looking for a posada! ✨")

 day = req.params.get("day")
 if not day:
 locations = json_locations()
 return func.HttpResponse(f"{json.dumps(locations)}", status_code=200)

 if day:
 locations = json_locations()
 posada = get_loc(day, locations)
 return func.HttpResponse(f"{json.dumps(posada)}", status_code=200)
 else:
 return func.HttpResponse("Please pass a day", status_code=400)


def json_locations():
 """Function to parse the json file with the locations,
 we use Pathlib to resolve the full path of the file
 """
 loc_path = Path("./posadas/data/locations.json").resolve()
 with open(loc_path, "r") as json_file:
 locations = json.load(json_file)
 return locations.get("locations")


def get_loc(day, locations):
 """This function searches for the location corresponding to the 
 query day. 
 We need to make sure the dates are actually converted into DateTime objects.
 """
 for posada in locations:

 date = datetime.datetime.strptime(posada.get("date"), "%B %d, %Y").date()
 if date.day == int(day):
 return posada

The code above allows the user to:

Provide a day as a query string to the function API in which case it only returns the details for the corresponding day (e.g. https://posadastrallard.azurewebsites.net/api/posadas/?day=16).
Submit a GET request to the primary endpoint so that it returns all of the dates and locations in the locations file.

After testing locally running func host start and making sure everything was working, I deployed my function app to Azure. I like using the Azure CLI for this kind of things (again a step-by-step can be found here).
If you have the Azure Functions extension for VS Code Installed, you can publish your app directly from there too, and it will save you some time.

After deploying, I made sure that my function was working correctly by performing a GET request:

Once the function is deployed, we can go ahead and create the CI/CD pipeline. For this challenge, I decided to use GitHub actions. To do so, we need to follow the next steps:

Create a service principal. This will allow us to deploy our function using GitHub actions. If you are using your command line with the Azure CLI or the Azure Cloud shell, you can use the following command:

 az ad sp create-for-rbac --name "myApp" \
 --role contributor \
 --scopes /subscriptions/<SUBSCRIPTION_ID>/resourceGroups/<RESOURCE_GROUP>/providers/Microsoft.Web/sites/<APP_NAME> --sdk-auth

Note that we are giving it only contributor access to restrict the scope of this access.

Now make sure to copy the output of the above command as you will need it. Head over to your GitHub repository where you have your function code go to Settings > Secrets Paste the output from when you created your service principal (note that you will need to add your subscription id too).
Now back in your local repository, we are going to create a .github/workflows directory. That is the location where all of our CI/CD pipeline definitions will be located for GitHub to be able to find them. Now let's create a python_function.yaml file (you can change the name).

I am going to explain the content, so you know what this is doing.

We want the pipeline to trigger at a push on the master branch. Also, we first need to check out our repository, so we use actions/checkout@master.

name: Python function

on:
 push:
 branches:
 - master

jobs:
 build-and-deploy:
 runs-on: ubuntu-latest
 steps:
 - name: "Checkout GitHub Action"
 uses: actions/checkout@master

Next, we login to Azure and set our Python environment. Here is where you also install dependencies.

 - name: "Login via Azure CLI"
 uses: azure/login@v1
 with:
 creds: ${{ secrets.AZURE_CREDENTIALS }}

 - name: Setup Python 3.7
 uses: actions/setup-python@v1
 with:
 python-version: 3.7

 - name: "Run pip"
 shell: bash
 run: |
 pushd .
 python -m pip install --upgrade pip
 pip install -r requirements.txt --target=".python_packages/lib/python3.7/site-packages"
 popd

Finally we publish our function:

 - name: "Run Azure Functions Action"
 uses: Azure/functions-action@v1
 id: fa
 with:
 app-name: posadastrallard
 package: "."

Now if we do git add .github/workflows/python_function.yaml and push we should see the workflow running straightaway under Actions:

Finally, you can make an update to the locations file, wait for the deployment to complete and see your app updated!

Success!

You can see the final Python Http Triggered function as well as the GitHub actions workflows in the GitHub repository shall you need more inspiration.

Want to submit your solution to this challenge? Build a solution locally and then submit an issue. If your solution doesn't involve code you can record a short video and submit it as a link in the issue desccription. Make sure to tell us which challenge the solution is for. We're excited to see what you build! Do you have comments or questions? Add them to the comments area below.

Watch for surprises all during December as we celebrate 25 Days of Serverless. Stay tuned here on dev.to as we feature challenges and solutions! Sign up for a free account on Azure to get ready for the challenges!