Every week, each of the develeap consultants writes a short weekly report, detailing last and next week’s tasks.
- Why is it needed?
- Who is it helping, and how?
- How do we write it fast?
- Who do we send it to?
All these questions and more are answered below.
Purpose
The weekly report serves several people and very different purposes:
Customer team leader
Having a weekly report allows your direct customer to gauge progress and see that she is receiving value. Even when you have good communication, and talk all day long, it is very typical that people loose sight of what has been achieved. A weekly report anchors this.
Develeap Team leader
A develeap team leader will often serve 8 different customers. Being able to stay in the picture without requiring long talks with many people is priceless
Customer group manager
Ultimately there is always somebody higher up that pays your salary. This person needs to be aware of the value given, so that he will be your champion when expenses are cut – and they always are. A weekly remider of this value is crucial.
Develeap Customer management
A customer manager (in some cases, the team leader) will talk with customer people once every 1-2 weeks. Being able to read the last report before calling the customer is key. Knowing how things went, and what flags were raised over the weeks is all important if a customer crisis ensues.
You
Giving your self 10 minutes a week to have a “checkpoint”: What am I doing? Why? Am I really delivering value? Do I know what to do in 3 days?
Structure
The weekly report is a simple mail with 4 parts. It should take you less than 10 minutes to write it:
- Tasks I completed this week
- Tasks I intend to complete next week
- Help I may need, and from whom
- Business goals / Roadmap / Why are these the tasks I am doing
The mail title is uniform: Weekly report dd – dd/mm
Examples
Here are some examples of reports written by consultants:
weekly report for the past (rather short, but very productive) week:
Task completed this week:
changed SB repo Master job to work against latest tags instead of latest Dev release – this is a direct improvement that can be achieved because of the merge request pipeline, we can check the container changed against the latest Dev (last release containers) and after merging, we test against the latest tags (the next dev release).
that way we have another validation for the next version will work as should.
job to destroy specific test environment – as requested by QA team , and as it made sense, a job to destroy a specific instance before the automatic destruction occurs. The job checks that the instance was created by jenkins (with regex) and if so, destroys the instance, this is necessary because some of the instances in the vultr account are crucial, so this reduces some of the risk. (currently in PR)
added promote ova job – spare some more manual work related to the ova, take an ova file from Kube folder, and promote it (moving the release location in the bucket, change permissions, change name).
helm3 migration – scripts changed to support newer syntax, script created to migrate existing running cluster on helm2 to helm3, some of the deployments passed some checking to pass convention with k8s openapi (as helm3 checks the chart for validation before actually applying them). status: currently in PR, needs to be tested in full by QA before merging.
refactor of SB pipeline and testing – as a collateral to the first point, we took the chance to change the pipelines to declarative.
Moreover, we changed the tests so they are running in a downstream job, the main advantage of it is that because the tests are happening in the PR before merging, and on the master branch after merging, that we can modify all the tests from there, instead of changing the tests in both pipelines.
daily dev release now supports a custom major.minor version – this is necessary when the release needs to be for example ‘03’, but we are already in april, so automatically it is created ‘04’. a change to script and pipeline to allow this override to happen. (currently in PR)
Tasks for upcoming week(s):
create an ova for docker registry
run crystal regression tests on build machine
help needed:
as stated before, i do not know how to run the crystal regression tests. and i need somebody to show me how in order to implement it correctly into the tests. (my requests left unanswered)
an explanation regarding the docker registry ova. in order to implement it correctly
Long term goals:
migrate to helm v3 ( a version which isn’t dependent on tiller)
‘trust’ the ci enough in terms of tests to be able to dev versions daily and automatically.
Start working on the CD process :
1. Working on a dynamic full deployment script for CD purposes – as i understood, there is still a discussion regarding the what where and why. so i will need further updates when it will be discussed and decided.
2. Use terraform iac to deploy production k8s clusters on vultr/aws
3. Allow dynamic deployments of test environments for developers and pipelines (ex. 3 nodes, 2 nodes, etc), support it in the pipeline(currently not supported)
although all of the above, i do have concern:
I truly feel that as much improvement happened and will happen to the jobs themselves, and the automation of part of the ci process already done, that as long as the tests included in the process won’t be improved, we would not be able to trust the ci enough.
I strongly advise concentrating on that in the upcoming month.
In order to achieve it, working close to Shai (the QA automation) is much necessary.
happy holiday and stay safe,
Dan
Hi,
Below, you will find my weekly report.
Business Goals in this report:
[1] Lower current production risk
[2] Prepare new production templates for AWS/Alibaba
[3] Support CMS developers
Tasks completed this week:
– [BG-1] Configure the new Elasticsearch (AWS) after Itamar’s team updated it on the weekend.
Updated the DNS records and modified security groups so that the application could communicate with the ES cluster. Delivered to Nadav.
– [BG-1] [DevOPS-95] Connect the artifactory package repository as a nuget repository to the build process of the microservice’s docker images. Delivered to Nadav.
– [BG-1] [DevOPS-96] Setup new ElastiCache redis based service for developers. Delivered to Niv.
– [BG-1] [DevOPS-43] Updated the SSL certificate of the old production (on Azure) API server. Delivered to Kate.
– [BG-3] [DevOPS-97] Fix the CMS staging jenkins deployment job. Delivered to Keren.
– [BG-1] [DevOPS-88] Provision a new SSO server on the new EKS VPC and traffic routed to the new SSO server. Delivered to Ronit.
– [BG-2] [DevOPS-8] Terraform for alibaba K8S cluster. WIP, not complete yet.
Tasks for next week:
– [BG-2] [DevOPS-8] Finalize Terraform for alibaba K8S cluster
– [BG-2] [DevOPS-100] Work on security and communication of the alibaba provisioned infrastructure.
– [BG-1] [DevOPS-87] Once the new staging is stable, proceed to continue working on the AWS new production environment.
May need help:
- Ronit to approve staging checklist – when we declare that an environment is ready.
- QA and R&D to approve the new environment once it’s ready.
- Niv to specify monitoring and alerts requirements.
Happy holiday!
Regards,
Kobi
Hi,
Below, you will find my weekly report.
Tasks completed this week:
- Received code review from Hadar, finished developing ‘sentinel_devops_tools’ library.
- Build jenkins pipeline to make use of the new code, and perform ‘add elastic ip to instance’ job. (ONGOING)
- Build jenkins pipeline to ‘add users to aws dev account’ job. (ONGOING)
- Build jenkins pipeline to ‘migrate deploy legacy agent’ job. (ONGOING)
Tasks for next week:
- Build jenkins pipeline to make use of the new code, and perform ‘add elastic ip to instance’ job. (ONGOING)
- Build jenkins pipeline to ‘add users to aws dev account’ job. (ONGOING)
- Build jenkins pipeline to ‘migrate deploy legacy agent’ job. (ONGOING)
May need help
- Understanding and knowing SentinelOne software product, related personnel, general team atmosphere and expectations better.
Long term goals
- Gain a better grasp of the different systems, working environments and processes.
- Fit in properly within the team and company.
- Being able to identify manual workflows that may need automation, and processes that may need attention.
- Delivering value by improving performance and quality of components.
Daniel Harsheffer, DevOps Professional
Adressees
The report is always sent to at least 2 people:
- Your direct customer
- Your develeap team leader
Often it is also sent to your managers manager, to the one that actually made the order and is sigining the monthly pay cheque.
It should always be written in a way that all these 3 will understand.
FAQ
- What about long tasks? If you have a task that takes several weeks, then the report will look awful. You never complete anything! This is not a mistake. It actually reflects that you are in trouble. Customer with very long tasks tend to lose interest in the middle, complain that they did not get value and lead to project failure. Long tasks (over 1 week) MUST be broken into shorter, 2-3 day tasks with clear names, a delivery goal and a customer that accepts them. If you don’t know how to do that – talk with your develeap team leader, and do it together. A week without a clear delivery to the customer is a failure.
- All my tasks are in Jira – do I need to write a weekly report? Yep. Jira can work well for task management, but it does not serve a crucial aspect: checkpoint. The weekly checkpoint is very important, and well worth the 10 minutes of thought it requires.
Does it replace my communication with the team leader? Never. It just helps maintain a context. If your team leader did not talk to you lately – talk to him.