GitHub & Microsoft Teams Integration
Seeking improvement opportunities to enhance productivity and collaboration is a crucial factor when working with technology. The GitHub integration for Microsoft Teams allows developers to improve their communication by automatically posting messages about issues, pull requests, deployment status, and more. Once GitHub and Microsoft Teams platforms are linked, this allows various options, such as adding comments, closing, and reopening issues or even making pull requests, without leaving your chatbox.
A considerable amount of time might be spent by developers while communicating about code changes, monitoring issues and other GitHub-related activities. This integration improves this communication and optimises the developer’s time, while also encouraging faster discussions on code reviews. All of this is happening right in your Microsoft Teams channel, which tends to be the natural place of ideas and collaboration.
Step 1 – Installation
First, we are going to install the GitHub App in our Microsoft Teams.
- Go to the Microsoft Teams app store and install the GitHub app or you can directly install it from here.


- Upon installation, a welcome message is displayed.
- Use the @GitHub handle to start interacting with the app

Step 2 – Get Started
At this stage, our Microsoft Teams and GitHub user accounts are not linked yet. The following will link the two accounts.
- Just authenticate to GitHub using a @github signing command or try to subscribe to your repository.

- A message “Connect GitHub account” is displayed as shown in the following image. Just click on the button to connect the GitHub account.

Once the channel is created.
- Go to the channel and look for the GitHub icon.
- if the icon is not visible at the bottom of the channel, you must click on the “…” and search for GitHub integration with Microsoft Teams, as shown in the following image.

- Once GitHub is set up on Microsoft We can subscribe to the repository, as shown in the following image.

- Once the repository is subscribed, we will receive notifications as described above.
This whole process should be done once. After that, we can subscribe to as many repositories as we need, following just steps 8 to 10.
GitHub provides a lot of features to customise your subscription and keep the team up-to-date without switching to different platforms.
For more information go through the GitHub Documentation:
https://github.com/integrations/microsoft-teams/blob/master/Readme.md
Click the here to read more of Zinkworks blogs.
A method to override external domain name resolution in coredns
- You are trying to replicate an issue that you observe in a different environment, in your dev K8s cluster. To successfully replicate the issue, you need to ensure that you use the same hostnames, application FQDNs that were used in the original environment.
- You are testing an application running on Kubernetes that requires access to third party external endpoints over the internet. You need to ensure that these third-party external connections are created towards some known, test services, not the actual ones.
- You need an alternative and a more centralized way to control the responses received to DNS queries by the application pods. (e.g. You do not like to use “hostAliases” option with K8s pods)
First, we are going to run a “dnsmasq” server in the same Kubernetes cluster as a pod. It will be associated with a configmap through which we can manipulate the DNS records. Other than that, the dnsmasq pod will be exposed via a clusterIP type Kubernetes service.
To run a “dnsmasq” server as a container, we can first create docker image using following Dockerfile.
As you may notice in the ENTRYPOINT of above, we are running “dnsmasq” in foreground (-d) as well as we pass a configuration file (-C) and a hosts (-H) file to it. During the build, these files do not necessarily need to exist in the docker image. However, during the runtime we will mount relevant configuration files to /var/dnsmasq/conf/dnsmasq.conf and /var/dnsmasq/hosts location accordingly.
Now you can build the docker image with “docker build –t dnsmasq:latest ” command. You may push it to a docker image repository that is accessible by your Kubernetes cluster, afterwards
Now let us create a couple of configmaps to pass the dnsmasq.conf and hosts files to the running dnsmasq pod.
In below example, we are creating a fake DNS record, that resolves www.zinkworks.com to 10.100.1.1 address. Also, we will create a host’s file record that maps example.zinkworks.com to 10.100.1.2
You can create above configmaps in the namespace where you will run the dnsmasq pod, using “kubectl create –f“or “kubectl apply –f” commands.
Next let us create a dnsmasq pod using the docker image built in step 1. We will also mount the configmaps created previously to /var/dnsmasq/conf/dnsmasq.conf and /var/dnsmasq/hosts as files.
Above is an example pod definition to run the dnsmasq container with desired configurations. Notice how, dnsmasq-conf and dnsmasq-hosts configmaps are mounted as files to the pod. Also notice the “NET_ADMIN” capability given to the container. This will allow you to run the container with UDP port 53.
You can create the pod by running “kubectl create –f” or “kubectl apply –f” commands on above pod definition.
Once the dnsmasq pod is created, you can confirm if it is running fine by looking at the pod logs.
Here is an example output. In this case, it is assumed that dnsmsq pod is created in dnsmasq namespace.
Finally, we will expose the dnsmasq pod via a kubernetes service.
In the future steps, we may need to use the service IP assigned to the dnsmsq service to send our DNS queries to the dnsmasq container. To find the service IP of the dnsmasq service, you can run “kubectl get svc” command on the namespace where you run dnsmasq pod.
In our example the dnsmasq service IP is 10.108.96.48.
You can further check if the domain name resolution is working as expected in the dnsmasq container by running a few nslookup commands from a different pod.
In below example, we are running a pod called ubuntu-debugger in the same cluster from which we can check the responses sent by the dnsmasq. It is assumed that ubuntu-debugger pod has nslookup utility.
Notice how in the first nslookup command for www.zinkworks.com has returned the actual public IP instead of the fake one we provided to the dnsmasq container in dnsmasq.conf file. This is because this external DNS queries are handled by the coredns and they are by default forwarded to the nameservers specified in /etc/resolv.conf file.
Now in the subsequent nslookup commands we specify the service IP of the dnsmasq service which is 10.108.96.48. This ensures that the DNS query is processed by our dnsmasq container directly. As you notice in the second nslookup command for www.zinkworks.com, We have received the fake IP we configured in the dnsmasq container through the dnsmasq.conf file.
Any other query that dnsmasq service cannot answer will be sent to the next nameserver in the chain. In our case it is 8.8.8.8
Now as you noticed in step 2 above, all external DNS queries are by default not forwarded to our dnsmasq container, unless we specify the nameserver in our query. This is not convenient. Therefore, next we look at how we can configure the coredns to forward all our external DNS queries to dnsmasq container by default.
First, we open the coredns configmap in edit mode by running the following command.
$ kubectl edit configmap –namespace kube-system coredns
This will open a similar configuration as shown below on your editor.
The highlighted “forward” section in above configuration should now be modified to forward the external DNS queries to our dnsmasq container.
After the modification the configmap should appear as shown below.
Next save and exit from the editor so that above change is now reflected to coredns configmap.
Finally, you can restart the coredns pods in kube-system namespace by deleting them. This will ensure that our modified configuration is loaded into the new instances of coredns pods that will come up after deleting the old replicas.
Here is the command to delete the current coredns pods.
$ kubectl delete pods –namespace kube-system –force –grace-period=0 $(kubectl get pods –namespace kube-system | grep coredns | awk -F ‘ ‘ ‘{print $1}’)
Now, let us run the same nslookup command on www.zinkworks.com from our ubuntu-debugger container to see if we are getting the expected response.
As expected, the queries for www.zinkworks.com and example.zinkworks.com return the fake IPs we configured in dnsmasq.conf and hosts file in dnsmasq pod.
To find out more about careers at Zinkworks click here.
Retrospectives: The Fuel to Continuous Improvement
What is Continuous Improvement?
Continuous Improvement is often an abstract and vague term to describe better ways of working. Within the context of business and technology, Continuous Improvement seeks to enhance every aspect of value in a team’s processes and products. By reducing waste, reducing burden, and increasing consistency, teams boost the value they produce towards their stakeholders. It is impossible to remove all waste, burden and inconsistency completely from the team’s work, but teams should work to minimize each one incrementally. This incremental change is what we refer to as Continuous Improvement. Let’s look at Continuous Improvement and how we can utilize its main driver – the “Retrospective”.
Continuous Improvement Lifecycle

Continuous Improvement in Sport
Let’s step back for a minute and look at Continuous Improvement in the world of sport. In 2002, Sir Dave Brailsford joined as head of the British Cycling team. Before Sir Dave’s leadership, British Cycling had won just one gold medal in almost 80 years. In the 2008 Beijing Olympics, Sir Dave led the British track cycling team to 7 out of 10 gold medals! After achieving this staggering result, he turned his focus towards “Team Sky” – Britain’s first-ever pro cycling team. He led Team Sky to 6 out of the last 9 Tour De France events, an impressive feat to say the least.
How did Sir Dave achieve this? Sir Dave held an MBA and used methods of Continuous Improvement when coaching his teams. He looked for small things to improve in how the team worked together, referring to these improvements as “marginal gains”.
“Forget about perfection; focus on progression and compound the improvements.” – Sir Dave Brailsford
The team hired a wind tunnel to understand and experiment with aerodynamics. They painted their truck’s floor white to detect and reduce dirt on the bikes. They even brought their own mattresses and pillows to each hotel to get a good night’s sleep! By regular retrospection, the team encouraged ownership and, eventually, everyone started to come up with their ideas for improvements which, in the end, led to their huge success. This is the power of Continuous Improvement. “Marginal gains” made frequently in the short term encourages growth and prosperity in the long term.
Continuous Improvement is an Engine
Think of Continuous Improvement as an engine. The purpose of an engine is to drive something forward in a given direction. Continuous Improvement should be the engine that drives your team forward to deliver more and more value each iteration.
All engines need fuel. Without fuel, the engine slows down and stops. If Continuous Improvement is your team’s engine, then the Retrospective (henceforth referred to as the ‘Retro’) is your team’s fuel. Like an engine without fuel, Continuous Improvement without Retros slows down and stops. A car that does not move forward becomes a stagnant, empty shell that is only nice to look at (many people own such cars!). We do not want to be stagnant teams, empty shells with nothing to drive us forward. We want to be innovative and come up with creative solutions to our own problems.
Forward progress gives us satisfaction in our jobs and without that sense of progress, we become scattered and burnt out. But to achieve progress and forward motion, we need fuel. We need Retros to provide fuel to our engine.
What is a Retro?
The Retro is a team meeting where space is created for everyone to learn and brainstorm ideas. It is important that the whole team contributes towards the Retro. A Retro in which only part of the team speaks up is not a good Retro. For example, it is common for the loudest person on the team to speak the most in Retros. Or maybe people do not want to speak up because the most experienced person will argue them down. But the Retro is one of the few places where all members of the team come together as equals. The Retro facilitator should work to ensure all members contribute and have their voices heard.
If the Retro is the fuel to your team’s engine, then it needs to be topped up frequently. Therefore, Retros should be scheduled regularly. They should be monthly at a minimum, but ideally more often. In between Retros, the team can test their experiment ideas and gather feedback for the next Retro. The Retro should also close out your team’s iteration period. For example, if your team works in cycles of two weeks, the Retro should be the last event of the cycle. By taking a Retro at the end of the cycle, it provides the team with the opportunity to plan for the next cycle. If your team has no cycle time, then pick one – teams always work best with defined timelines.
Retros provide the opportunity for the team to give feedback about themselves, their processes, and their product. Whether you have been part of the team for a day or a decade, your opinion is equally valid in your team’s Retro.
If you are new to the team, this is your opportunity to speak up about the things you find difficult and frustrating. Are you happy with the onboarding process? Are you invited to pair program on tasks? Do you understand your objectives as part of the larger team? As a new team member, it is up to both you and the team to make sure you are integrated and valuable to the people around you. If something is difficult as a new member, then have the courage to speak up and be honest in your team’s Retro.
If you have been with your team for a longer period, you likely have valuable insights into the biggest problems you and your team face. Is the team’s quality sufficient? Is there enough innovation and experiments happening in the team? Are you excited, bored, or burnt out with your work? With experience comes more expectations, but that does not mean you should expect to be stressed or under pressure all the time. Use the team’s Retro to voice your concerns with your teammates. They just might surprise you!
“What experiment do we want to run next?”
This is the question the team should work to answer in their Retro. Simply having a meeting called “Team Retro” will not achieve improvements without a solid outcome and plan for what happens afterwards. The real work is done between Retros where the chosen experiments are tried and tested. The Retro allows the team to learn about problems, identify solutions and pick an experiment going forward using methods like the 3 questions: “What went well? What did not go well? What should we improve?”
Think back to the experiments Sir Dave ran with his teams. White paint, mattresses, hand washing. These are not particularly profound ideas. I am sure there were many experiments and ideas Sir Dave’s team tried which came to no avail. However, each time they tested something out, whether it succeeded or failed, the team learned something new. There was no single experiment that won gold for the team. Each success built on the last until, eventually, enough 1% marginal gains were made to achieve the gold.
A good Retro experiment will like the British cycling team’s experiments – short, actionable, and valuable.
It needs to be short so the team can commit to it on top of their other work. “Pair program on critical tasks” is better than “Re-architect our software to support faster deployment”.
It needs to be actionable so the team do not jump through hoops to complete it. “Order our stand-up tasks by priority instead of person” is better than “Suggest a new tool for ticket tracking to the organisation”.
And it needs to be valuable so that the team can add it to their ways of working. “Scrum Master to close stand-up after 15 minutes” is more valuable than “Create unit tests for this deprecated piece of code”.
Benefits of Retros
Agency is a psychological term that means ‘I can act on my behalf. A team with a sense of agency can act independently to control and change their surroundings. By raising their problems in the Retro, the team empowers themselves to come up with their own solutions. They develop ownership over their environment and push for change where change is needed.
“How do you feel?” “…Fine, and you?”
This is a common response when you throw the ‘f’ word at someone (feelings). While we don’t like to share our feelings with other people, it can be a valuable piece of feedback for a team to understand each other’s moods. In my team, we start off the Retro with a quick word from everyone on their mood in the past few weeks. We have yet to hear the word ‘fine’. Usually we hear ‘stressed’, ‘anxious’, ‘messy’ or ‘productive’, ‘fun’ and ‘exciting’.
Each answer gives a good insight into how the team’s mood is. A positive overall answer indicates the team is doing something well and should continue to do so. A negative reaction indicates something needs to change and the retro should then focus on alleviating those negative points going forward.
Any good team understands the need to innovate. Teams can only make Continuous Improvements if they have created the environment to brainstorm and innovate. Their Retro facilitates such an environment where ideas, both good and bad, are welcome. Without creative ideas, we cannot innovate. Without innovation, we cannot discover those marginal gains Sir Dave talked about. The Retro provides the space to identify these 1% improvements we can bring to the team. If each Retro facilitates just a 1% improvement to your team, imagine the massive changes that could happen over a year.
What Next?
First things first – set up regular Retros with your team if you are not already doing so. Within each Retro, focus on a particular area the team would like to improve. This could be quality, bugs, meetings, processes, teamwork or anything else the team thinks is a priority. For each Retro, focus on answering the question: “What experiment do we want to run next?” Once the team picks an experiment to focus on, plan it into the next iteration and track whether it succeeds or fails.
Remember, the team’s retro does not have to be a complicated or lengthy meeting. However, it does need to be taken regularly to yield those marginal gains and fuel your team’s Continuous Improvement.
You can find more of David at www.dcaulfield.com.
To find out about our open positions and how you can join the Zinkworks team visit our careers page.
Zinkworks Education Programme - Berchris's Experience
Senior Associate Berchris describes his experience furthering his education through the further education programme here at Zinkworks:
“Before I joined Zinkworks I was always interested in doing a master’s degree in my field but found it hard to get the time and support to do so knowing the costs would also be high. At the time of joining Zinkworks, the company did not have any further education program in place, however, once I decided to pursue the course, I asked the company for support with this. I didn’t know what to expect as there was nothing established in terms of support for people returning to education within the company, I was surprised and happy to find out that Zinkworks were happy to give all the support required, including financial support. I was very excited about this as it showed how the company care for its employees as I was only with Zinkworks for a little more than a year at this time, I found their attitude so amazing!
A few weeks later I started the MSc. In Software Engineer course in the Technological University of the Shannon. Doing this course and working at the same time has been a real challenge for me especially as I need time to spend with my family also. I must say that it would have been harder without the support of Zinkworks. They have been very flexible when I would need some time off for study or exams or when I would need to attend classes. I am very close to the end of the course now; I have finished all the subjects and I am about to deliver the final project. I’m relieved and happy to be completing the course, I am also very grateful to work in a company that is always willing to support their employees in their path to progress their career through learning. Thank you Zinkworks for all your help so far.”
Since Berchris started his further education endeavour Zinkworks has employed an extensive employee-driven education programme as development and learning is at the core of Zinkworks values.
If joining the Zinkworks team and our further education programme is of interest to you, contact us to find out more.
To find out more from Berchris and read some of his work visit his Github and Medium.com accounts.
Changing Careers - Declan's Experience
Here is what Scrum Master Declan McDaid has to say about his experience changing his career path to join the tech world after 14 years –
“I started my career as a Concrete finisher after I completed my Leaving Certificate and having worked 14 years in the building industry Ireland suffered a recession. As a result, I was made redundant, soon after I started working in a bookmaker’s shop. While working in the bookmakers I somehow became the IT guy for the company (turn it off and turn it on again). I really liked the troubleshooting and with some persuading from my wife, I decided to pursue a career in IT.
In 2012, I looked at a few different courses and settled for a level 6 in IT support in LYIT. The reason for choosing this course was that it was 18 months with a 6-months work placement in the middle. Due to not being in education for 16 years I thought this would be the best fit for me. During the last semester, LYIT was offering a level 9 DevOps course for the first time. I applied for a place on this and was successful. Having not heard of DevOps until this I was curious to learn more.
The course enforced DevOps and the agile methodology, work placement was a mandatory part of the course. On completion of my work placement, I was offered a development role with the company. After 1 year with that team, I joined a new team working with data integration team that was tasked with making data available from microservices to the current mainframe system. While I was happy doing data integration work, I still had a keen interest in a career in DevOps.
I heard about (Neueda Technologies Athlone) Zinkworks through a current Zinkworks employee and they were recruiting engineers. I applied through the website. The recruitment process was a pleasant experience. I was successful with the interview and was offered a role. I was still apprehensive about leaving TCS but thankfully Orlagh reassured me about it being a good place to work and after 6 or so months here I’d have to say it has been the right choice.
I am currently a Scrum Master for a team working on deploying applications on AWS with the latest technologies. Aileen organised Scrum Master training for me a few weeks after joining which I completed, and I am now a certified Scrum Master with the Scrum Alliance. After 6 or so months here I’d have to say it has been the right choice. It has been an educational and enjoyable experience (can’t wait for the next company outing) to date, to make it even better I am now the proud owner of a Mac book which I won from Zinkworks on a draw which was held for all employees who have had a referral in 2021.”
Visit our careers page if joining the Zinkworks team is of interest to you!
Zinkworks Innovation Team
The Innovation Team is the research and development side of Zinkworks, there is a mixture of senior developers who have worked in the Telecommunications world for many years and junior developers who bring their own way of working and knowledge to the team.
Our work can range from developing bespoke apps for the company or researching the latest technology for potential clients.
Most of our work to date has been researching the latest 5G projects and advancements. Like working on the open radio access network known as the Oran project, which is an open-source Ran system developed by some of the biggest companies in the Telecommunications sphere.
ONAP is another open-source framework for the 5G network which the team spent a lot of time researching and testing. We were able to pinpoint some areas in the project that need adjustments to make them ready for real-world use, for example, the deployment was overly complex, and the document was not user-friendly. We started to develop a framework for this project that would make the deployment of Oran a one-click installation.
The team also began researching a solution for data collection of a 5G network, if enough data is collected for a network, we then send that data to be modelled using machine learning and artificial intelligence. These models could be then used to improve the network and enforce Quality of Service (QoS).
Another aspect for the collection of data inside a 5G network would be that it can give the owner of the network a more in-depth view, with the use of metrics and a visual dashboard the user can understand the network and its inner workings.
Some of the technology that the team use would be Springboot and Java, React and Node along with JavaScript, Golang, Docker, and AWS for our cloud deployment.
I would like to thank all the team for their work.
– Aaron Fortune
Click here to find out more about our services and what we do here at Zinkworks.
Becoming Zinkworks
We are Next generation connectivity.
We are Zinkworks.
Zinkworks (formerly Neueda Technologies Athlone) is our new Company name going forward. We are always imagining, learning, and creating new technologies that transform the world into a more connected universe.
This new name and brand identity is a critical point that allows us to make definitive and tangible decisions as to what we represent and what direction we go in.
Working primarily in the Telecommunications and Financial sector, along with our internal innovation team, we work with new and exciting technologies. Working with the newest developments in these areas with our clients, we aim to make advances that is instrumental for each sector we work with to prosper. This also allows us to progress into other areas and work with new ground-breaking developments in the Software development world.
Zinkworks aims to project a culture of learning, support, friendship, and diversity to name a few. Our 150 employees are the driving force behind our success. We aspire to make Zinkworks the most desired place for them to work. We do this through providing support and encouragement for people to learn and develop in their careers. Whether this be through further education endeavours or through a clearly defined career path, we like to ensure people get to achieve their goals.
In just 4 years since our opening, we have grown in a positive trajectory. We are excited and eager to see what the next 4 years of Zinkworks will bring.
“Zinkworks immediately demonstrates itself as a flat organisation. There is no hierarchy of employees. Everyone is equal and are treated as such. No yarn is spun when messages are delivered to employees. Everything is direct. Everyone’s voice is listened to. And everyone’s feedback is taken onboard.”
– David McWeeney, Software Engineer