How can a Devops Engineer save money using Azure?1 - Shutting down Azure VM’s correctly2 - Using Azure DevTestLabs effectively 1) Just like the annoying person accidentally leaving a light on (guilty), one of the biggest mistakes Devops/Developers can make when using Microsoft Azure is incorrectly closing VM’s (Azure virtual machines) that are no longer needed.Simply flicking a switch to turn off the VM won’t work but there’s a better way to achieve this:- Ensure the VM is in a Stopped (Deallocated) state - Use the Azure Management Portal to find the Virtual Machine blade for the VM you want to stop and click Shutdown2) Azure DevTest Labs allows you to create servers you’ll need at specific times during the day or create a schedule (say after 5:30 or at a weekend) in case your Dev team leave them on accidentally.Plus, Azure DevTest Labs is a free-to-use tool. You only pay for the VM’s it’s on.

​Taking the leap and starting your freelance career is like setting up any other business, it's a time filled with excitement, but it can be daunting. You’ve made your decision for all of the right reasons; you want some more autonomy, you’re excited about meeting new people, working on different products and you’re loving the idea of learning new technologies. That’s without even mentioning the increase in pay.Hopefully in this article you can pick up some useful points I’ve taken from client feedback and the feedback of more experienced freelancers.​Preparing to freelanceLogistics - freelancing usually requires an extra degree of geographical flexibility. It helps to find how far you can feasibly travel on a daily basis. 60km may sound achievable in theory, but you don’t want to have to let your very first client down because you misjudged the traffic on that route. Try to figure out which main towns and cities you can easily reach.Rate – this is often the most under-researched aspectwith new freelancers. I often have conversations where the only research has been to ask a far more experienced freelancer at their current company what they are making. My advice would be to seek the advice of people you trust. This might be a specialist recruiter; someone you respect in a managerial position or maybe seek out a freelancer of a similar experience level through LinkedIn.Availability - leaving a secure job and jumping into the unknown is a tough thing to do, but the most successful first-time freelancers I’ve worked with have always either handed in their notice already or negotiated a reduced notice with their current company. Availability comes up in every single interview and in my experience when a client has multiple options, they will lean towards the person who is available sooner.Skill set - this is for those of you who plan on going freelance eventually but aren’t ready yet. Don’t get stuck working with outdated technologies and try to avoid becoming a “generalist”. Freelancer roles are often created when an expert is needed. It’s rare that a company will hire a freelancer to do general tasks. They are usually brought on for their in-depth knowledge of a particular language or framework.Keep an open mind - in an ideal world your first freelance role would be a 12-month contract with your dream company. In reality it might be only for 2-months, but that’s okay. That 2-month contract could be extended and last for 3 years. Alternatively, something you learn in those 2-months might help to secure you the dream job we were just talking about next time around. ​Building your personal brandReferences - when you’re up and running as a freelancer try to get a written reference from every client you’ve worked at. It might sound obvious, and you might not want to share them with every recruiter you speak to. However, surprisingly few people actually keep a list of references and it's a simple way to stand out from the crowd. LinkedIn - keeping your LinkedIn up to date, populated in detail and maintaining a good network is excellent marketing for your business. Clients will often look up your profile ahead of an interview, a mutual connection can be a great conversation starter or even offer up a recommendation.Take pride in your CV – as a freelancer your CV is a window to your business and the portfolio of your work so far. Would you brush past typos in your code, or leave formatting errors on your company website?Self-develop - study the trends in the market and make sure you get ahead of them. Take up certifications and go to seminars on the next big technological advancement. The best developers I’ve worked with are active within their commmunity. Attending conferences, meet ups and completing courses will keep your CV up-to-date and improve your network. ​The best characteristics of a freelancer Communication - this is the most under-rated tool available to any freelancer. If I was going to pinpoint the number 1 reason that freelancers don’t work out, it’s definitely not technical ability.- Clear and regular communication around the progress of your work. Be honest, give detailed reports and manage expectations. - Don't be afraid to ask questions. There is nothing more frustrating for a client than having someone take a day to figure something out which could have been resolved with a simple question (especially if that day costs them €700).- Phone ahead - if you're unwell or your train is running late, 99% of clients don't mind as long as you call ahead to let them know. It might feel like this is unnecessary when you're self-employed but as a professional courtesy, it should be standard practice. Willingness to learn and take responsibility - while a client will hire you for your specialist knowledge, they might also need to utilize your experience on different parts of the project. Try to view this as a positive thing. A common theme in positive references I receive point to freelancers using their initiative to solve a problem outside of their field of expertise.

​Finding a new role can be stressful, whether it's born out of necessity or simply searching for that new challenge! Fortunately, an industry exists that should help this process go a little smoother. But, there are so many recruiters out there all fighting for your CV, who should represent you?​1. How did they approach you?The first (and perhaps most obvious) to consider is the method of approach. One thing that can frustrate people is to be bombarded with messages, emails, and calls without being given a reason to be interested or want to chat!​Look out for signs that this recruiter has actually identified you as a relevant candidate.​This could be as simple as them immediately sharing information on a relevant role or detailing why their services are going to be of particular use to you. Whilst receiving a call from an unknown number can sometimes be inconvenient, you should be able to tell in the first 10 seconds whether this recruiter is worth your time.​The age of LinkedIn and the option to tick 'Open to New Opportunities' offers recruiters another method of reaching out, but this can sometimes feel a little impersonal.​It's noticeable when a recruiter has taken the time to really study your profile and add that personal touch in a message or connection request.​​2. Have they listened?Often you will first have a phone call so that the recruiter can understand your situation and experience - this will dictate much of your future relationship.​Are they asking relevant questions to determine what you're actually looking for?​Your career aspirations and your motivations are hugely important topics to cover if you're going to find the right job (and it's evident when a recruiter either hasn't asked or doesn't want to know!).​There's nothing more frustrating than the feeling you've not been listened to, and recruiters do sometimes have a reputation for neglecting to understand what's important to a potential candidate; to simply 'connect the dots' and deliver technically relevant candidates to their clients.​But that's not to say that the technical side isn't important too.​If they're not asking appropriate technical questions about your experience and previous roles, then it's unlikely they'll be able to provide you with a suitable vacancy (and they certainly might not be the best person to choose to convince companies that you're a good fit!).​​3. TransparencyA successful relationship with a recruiter should be based on honesty from both sides.​A good sign you've picked the right one is that they pay attention to your other processes and can justify why they're doing so.​Often this can seem unimportant, but it's a key part of a recruiter's job to really know their candidate's situation and communicate this to their clients in order to manage everything properly. For example, with this information, they have the ability to introduce urgency to schedule interviews quicker or demonstrate to clients that you're as good as your CV suggests.​This transparency works both ways though. It's crucial that you're honest about your feelings towards roles and companies in order for the recruiter to be able to give you the best chance of securing the one you want.​A good recruiter will be consistently asking you the difficult questions - to best understand your thoughts and (sometimes ever-changing) opinions throughout the process.​​4. AdviceThe last thing to consider is the advice given by a recruiter.​It's imperative that you trust your recruiter and the transparency discussed previously should give you the confidence to do so.​Whilst it's evident that a recruiter will often have their own desired outcome of processes with a candidate, this doesn't mean they can't offer useful advice. At the end of the day, it's in a recruiter's best interest to find you a place you love and want to stay at.​Admittedly, it's certainly worth sometimes being wary of advice if it seems pushy or rash, but a recruiter will often have more experience than you regarding interview processes and should have a great understanding of the clients they represent.​You've picked the right recruiter when you feel confident they're advising you to make the decision best for you.​They can often give a different perspective and good foresight regarding potential issues or obstacles throughout the job-search.​​Hopefully, this has given you a few things to take into consideration when deciding on your next recruiter. What else do you think is important in a relationship with a recruiter? I'd be really interested to hear people's thoughts or past experiences, please comment anything relevant down below!​​

How can you create an effective CI/CD pipeline?Devops may be one of the haziest terms in software development, but most of us agree that five activities make devops what it is: continuous integration, continuous delivery, cloud infrastructure, test automation, and configuration management. If you do these five things, you do ‘devops’. Clearly, all five are important to get right, but all too easy to get wrong. In particular, continuous integration and continuous delivery (CI/CD) may be the most difficult devops moves to master.Continuous integration (CI) is a process in which developers and testers collaboratively validate new code. Traditionally, developers wrote code and integrated it once a month for testing. That was inefficient—a mistake in code from four weeks ago could force the developers to revise code written one week ago. To overcome that problem, CI depends on automation to integrate and test code continuously. Scrum teams using CI commit code daily at the very least, while a majority of them commit code for every change introduced.Continuous delivery (CD) is the process of continuously creating releasable artifacts. Some companies release to users once or even multiple times a day, while others release the software at a slower pace for market reasons. Either way, the ability to release is tested continuously. Continuous deployment is possible thanks to cloud environments. Servers are set up such that you can deploy to production without shutting down and manually updating servers.Thus, CI/CD is a process for continuous development, testing, and delivery of new code. Some companies like Facebook and Netflix use CI/CD to complete 10 or more releases per week. Other companies struggle to hit that pace because they succumb to one or more of five pitfalls I’ll discuss next.CI/CD pitfall #1: Automating the wrong processes firstThis trap tends to strike organizations making the shift from waterfall development to devops. New organizations have the advantage of implementing CI/CD from scratch. Existing companies have to journey gradually from manual to highly automated development. The full transition can take several months, which means you need to be iterative in how you adopt CI/CD.When you ask, “Does this need to be automated now?” run through the following checklist:How frequently is the process or scenario repeated?How long is the process?What people and resource dependencies are involved in the process? Are they causing delays in CI/CD?Is the process error-prone if it is not automated?What is the urgency in getting the process automated?Using this checklist, you can prioritize the steps in a CI/CD implementation. First and foremost, automate the process for compiling code. Ideally, you will integrate code multiple times per day (1). Manually, the process takes a few minutes to a couple of hours (2). That stalls output until the compiler finishes the task (3). It is also susceptible to human error (4), and because CI/CD is a pipe dream without automated integration, this is urgent (5).We can run the same checklist on testing. As you transition to CI/CD, you might wonder: Should we automate functional testing or UI testing first? Both will be repeated at least once per day (1). Both can take two to three hours for a medium-sized application (2). But they involve multiple dependencies (3). If you automate functional testing, you may not have to update the automation script that frequently. The UI, on the other hand, often changes and thus requires frequent script changes. Although both are error-prone (4), you should prioritize functional testing before UI testing to make the best use of your resources (5).Let’s do this one more time with the process of setting up environments. This scenario is only repeated frequently if you’re on a hiring spree or experiencing heavy churn (1). It’s a rather time-consuming process that can take several hours if not days (2). New team members can’t do anything helpful without environments, so clearly there is a dependency and delay (3). I wouldn’t say that the process is error-prone (4), so is it still urgent? (5) I lean toward yes, but I’d still prioritize integration and functional testing first.There is no such thing as ‘overautomating’. If you had unlimited resources, you would automate everything possible. That said, you cannot achieve total test automation. Sometimes you can break down tasks into smaller segments and automate in patches. Sometimes you should simply document the process in detail and execute it manually.CI/CD pitfall #2: Confusing continuous deployment for continuous deliveryContinuous deployment is the concept that every change made in the code base will be deployed almost immediately to production if the results of the pipeline are successful. This is terrifying to most organizations because rapid product changes can scare away users.Companies believe that if they do not practice continuous deployment, they are not doing CD. They fail to distinguish between continuous deployment and continuous delivery.Continuous delivery is the concept that every change to the code base goes through the pipeline up to the point of deploying to nonproduction environments. The team finds and addresses issues immediately, not later when they plan to release the code base.The codebase is always at a quality level that is safe for release. When to release the codebase to production is a business decision.Whereas continuous deployment unsettles most organizations, continuous delivery resonates with them. Continuous delivery gives them control over product rollout, functionality, and risk factors. There is time for alpha testing, for beta customers, for early adopters, and so on.CI/CD pitfall #3: Lack of meaningful dashboards and metricsIn CI/CD implementations, the scrum team may create a dashboard before members know what they need to track. As a result, the team falls prey to a logical fallacy: “These are the metrics we have, so they must be important.” Instead, perform a progressive assessment before designing a dashboard.Different members of an IT organization, and even various members of a scrum team, have different priorities. For instance, the folks in a network operation center (NOC) love red, yellow, and green indicators. Such traffic light dashboards enable NOC staff to distinguish problems without reading dense text or taxing their analytical abilities. Traffic lights help make hundreds of servers manageable.You might be tempted to use a traffic light dashboard for CI/CD too. Green, we’re on track. Yellow, we’re off track, but we have a plan to address that. Red, we’re off track and likely need to change our objectives.That dashboard is probably useful to a scrum master, but what about the Product Owner or the CTO? If a scrum team has 350 hours of work ahead for a two-week sprint, and its 10 members are accountable for 35 hours each, they would receive a corresponding number of story points. Upper management might be less interested in the status of story points and more curious about the “burndown” rate: the speed of task completion. Do team members carry their loads? How quickly? Are they improving over time?Unfortunately, burndown rates could be misleading if the various stakeholders don’t understand the scrum team’s agreed-upon habits. Some teams burn down points early as they go. Others wait until near the end of the sprint to burn down open points. The dashboard should take that into account.      If you can assess what data everyone wants and establish a standard narrative for what that data means, then you can design a useful dashboard. But don’t obsess over substance at the expense of appearance. Ask how stakeholders want it to look. Would graphs, text, or numbers be best?These are the considerations to investigate in a progressive assessment. They illustrate how tricky it is to make a useful CI/CD dashboard—and to make everyone happy. Too often, the most vocal team member hijacks the process, and others feel frustrated that the dashboard meets only one person’s preferences. Listen to everyone.  CI/CD pitfall #4: Lack of coordination between continuous integration and continuous deliveryThis pitfall takes us back to our consensus definition of devops, which holds that continuous integration and continuous delivery are two different items. CI feeds CD. Implementing a decent continuous integration pipeline and a full continuous delivery system takes months and requires collaboration. Quality assurance, the devops team, ops engineers, scrum masters—all must contribute. Perhaps the toughest aspect of CI/CD is this human factor rather than any technical challenge we’ve discussed. Just as you can’t program a healthy relationship between two people, you cannot automate collaboration and communication.To gauge this level of coordination, benchmark your CI/CD process against the best in the business. Companies like Netflix can complete integration, testing, and delivery in a matter of two to three hours. They established a system that passes code from hand to hand without indecision and discussion. No, it’s not 100 percent automated because that is impossible with current technology.CI/CD pitfall #5: Balancing the frequency of running continuous integration jobs and resource utilizationContinuous integration jobs are supposed to be triggered for every change that is introduced in the code. Successful jobs allow the changes to go through while failures reject the changes. This encourages developers to check-in smaller chunks of code, triggering more builds in a day. However, unnecessary continuous integration jobs consume resources, which wastes time and money.Because this process involves a lot of resource utilisation (CPU, power, time), the software should be broken into smaller components to create faster-running pipelines. Or the continuous integration jobs should be designed to batch check-ins that are first tested locally. The goal is to find a balance between the frequency of executing continuous integration jobs and the utilization of resources.Keep the goal in sightAs we dig into the pitfalls of CI/CD—complete with all of its esoteric terminology—it’s easy to lose sight of why this matters. Ultimately, CI/CD is essential because it meets business goals.Technology executives know that continuous evolution, quick fixes, and quality results create and retain customers. They know that a failed release invites a bludgeon to App Store reviews, and regaining high reviews is harder than keeping them. Devops might create a better work experience for your team, but that is not why companies implement devops.Simply put, the pitfalls of CI/CD are worth reviewing because billions of euros are at stake. While I don’t suggest you add a stock ticker or App Store review tracker to your CI/CD dashboard, I do urge you to stay ahead of this. A lot depends on the correct establishment of CI/CD.Write something here...